Device assisted CDR creation, aggregation, mediation and billing

ABSTRACT

Device assisted CDR creation, aggregation, mediation and billing is provided. In some embodiments, device assisted CDR creation, aggregation, mediation and billing for a wireless network includes collecting device generated service usage information for one or more devices in wireless communication on the wireless network; and providing the device generated service usage information in a syntax (e.g., a device assisted charging data record (CDR)) and a communication protocol (e.g., 3GPP, 3GPP2, or other communication protocols) that can be used by other network devices to augment or replace network generated service usage information for the one or more devices in wireless communication on the wireless network.

CROSS REFERENCE TO OTHER APPLICATIONS

This application claims priority to U.S. Provisional Patent ApplicationNo. 61/206,354 entitled SERVICES POLICY COMMUNICATION SYSTEM AND METHODfiled Jan. 28, 2009, U.S. Provisional Patent Application No. 61/206,944entitled SERVICES POLICY COMMUNICATION SYSTEM AND METHOD filed Feb. 4,2009, U.S. Provisional Application No. 61/207,393 entitled SERVICESPOLICY COMMUNICATION SYSTEM AND METHOD filed Feb. 10, 2009, U.S.Provisional Patent Application No. 61/207,739 entitled SERVICES POLICYCOMMUNICATION SYSTEM AND METHOD filed on Feb. 13, 2009, U.S. ProvisionalPatent Application No. 61/270,353 entitled DEVICE ASSISTED CDR CREATION,AGGREGATION, MEDIATION AND BILLING filed on Jul. 6, 2009, and U.S.Provisional Patent Application No. 61/264,126 entitled DEVICE ASSISTEDSERVICES ACTIVITY MAP filed on Nov. 24, 2009, which are incorporatedherein by reference for all purposes.

This application is a continuation in part of co-pending U.S. patentapplication Ser. No. 12/380,778, entitled VERIFIABLE DEVICE ASSISTEDSERVICE USAGE BILLING WITH INTEGRATED ACCOUNTING, MEDIATION ACCOUNTING,AND MULTI-ACCOUNT, filed on Mar. 2, 2009, which is incorporated hereinby reference for all purposes; and U.S. patent application Ser. No.12/380,771, entitled VERIFIABLE SERVICE BILLING FOR INTERMEDIATENETWORKING DEVICES, filed on Mar. 2, 2009, which is incorporated hereinby reference for all purposes, and which each claims priority to U.S.Provisional Patent Application No. 61/206,354 entitled SERVICES POLICYCOMMUNICATION SYSTEM AND METHOD filed Jan. 28, 2009, U.S. ProvisionalPatent Application No. 61/206,944 entitled SERVICES POLICY COMMUNICATIONSYSTEM AND METHOD filed Feb. 4, 2009, U.S. Provisional Application No.61/207,393 entitled SERVICES POLICY COMMUNICATION SYSTEM AND METHODfiled Feb. 10, 2009, and U.S. Provisional Patent Application No.61/207,739 entitled SERVICES POLICY COMMUNICATION SYSTEM AND METHODfiled on Feb. 13, 2009, which are incorporated herein by reference forall purposes.

BACKGROUND OF THE INVENTION

With the advent of mass market digital communications and contentdistribution, many access networks such as wireless networks, cablenetworks and DSL (Digital Subscriber Line) networks are pressed for usercapacity, with, for example, EVDO (Evolution-Data Optimized), HSPA (HighSpeed Packet Access), LTE (Long Term Evolution), WiMax (WorldwideInteroperability for Microwave Access), and Wi-Fi (Wireless Fidelity)wireless networks increasingly becoming user capacity constrained.Although wireless network capacity will increase with new highercapacity wireless radio access technologies, such as MIMO(Multiple-Input Multiple-Output), and with more frequency spectrum beingdeployed in the future, these capacity gains are likely to be less thanwhat is required to meet growing digital networking demand.

Similarly, although wire line access networks, such as cable and DSL,can have higher average capacity per user, wire line user serviceconsumption habits are trending toward very high bandwidth applicationsthat can quickly consume the available capacity and degrade overallnetwork service experience. Because some components of service providercosts go up with increasing bandwidth, this trend will also negativelyimpact service provider profits.

BRIEF DESCRIPTION OF THE DRAWINGS

Various embodiments are disclosed in the following detailed descriptionand the accompanying drawings.

FIG. 1 illustrates a wireless network architecture for providing deviceassisted CDR creation, aggregation, mediation and billing in accordancewith some embodiments.

FIG. 2 illustrates another wireless network architecture for providingdevice assisted CDR creation, aggregation, mediation and billing inaccordance with some embodiments.

FIG. 3 illustrates another wireless network architecture for providingdevice assisted CDR creation, aggregation, mediation and billing inaccordance with some embodiments.

FIG. 4 illustrates provisioning of a wireless network for providingdevice assisted CDR creation, aggregation, mediation and billing inaccordance with some embodiments.

FIG. 5 illustrates a network architecture for providing device assistedCDRs in accordance with some embodiments.

FIG. 6 illustrates another network architecture for providing deviceassisted CDRs in accordance with some embodiments.

FIG. 7 illustrates another network architecture for providing deviceassisted CDRs in accordance with some embodiments.

FIG. 8 illustrates another network architecture for providing deviceassisted CDRs in accordance with some embodiments.

FIG. 9 is a functional diagram illustrating a device based serviceprocessor and a service controller in accordance with some embodiments.

FIG. 10 provides a table summarizing various service processerfunctional elements in accordance with some embodiments.

FIG. 11 provides a table summarizing various service controllerfunctional elements in accordance with some embodiments.

FIG. 12 illustrates a device stack providing various service usagemeasurement from various points in the networking stack for a servicemonitor agent, a billing agent, and an access control integrity agent toassist in verifying the service usage measures and billing reports inaccordance with some embodiments.

FIG. 13 illustrates an embodiment similar to FIG. 12 in which some ofthe service processor is implemented on the modem and some of theservice processor is implemented on the device application processor inaccordance with some embodiments.

FIG. 14 illustrates various embodiments of intermediate networkingdevices that include a service processor for the purpose of verifiableservice usage measurement, reporting, and billing reports in accordancewith some embodiments.

FIG. 15 illustrates a wireless network architecture for providing deviceassisted CDR creation, aggregation, mediation and billing including aproxy server in accordance with some embodiments.

DETAILED DESCRIPTION

The invention can be implemented in numerous ways, including as aprocess; an apparatus; a system; a composition of matter; a computerprogram product embodied on a computer readable storage medium; and/or aprocessor, such as a processor configured to execute instructions storedon and/or provided by a memory coupled to the processor. In thisspecification, these implementations, or any other form that theinvention may take, may be referred to as techniques. In general, theorder of the steps of disclosed processes may be altered within thescope of the invention. Unless stated otherwise, a component such as aprocessor or a memory described as being configured to perform a taskmay be implemented as a general component that is temporarily configuredto perform the task at a given time or a specific component that ismanufactured to perform the task. As used herein, the term ‘processor’refers to one or more devices, circuits, and/or processing coresconfigured to process data, such as computer program instructions.

A detailed description of one or more embodiments of the invention isprovided below along with accompanying figures that illustrate theprinciples of the invention. The invention is described in connectionwith such embodiments, but the invention is not limited to anyembodiment. The scope of the invention is limited only by the claims andthe invention encompasses numerous alternatives, modifications andequivalents. Numerous specific details are set forth in the followingdescription in order to provide a thorough understanding of theinvention. These details are provided for the purpose of example and theinvention may be practiced according to the claims without some or allof these specific details. For the purpose of clarity, technicalmaterial that is known in the technical fields related to the inventionhas not been described in detail so that the invention is notunnecessarily obscured.

There are many new types of digital devices where it is becomingdesirable, for example, to connect these devices to wireless networksincluding wireless wide area networks (WWAN, such as 3G and 4G) and/orwireless local area (WLAN) networks. These devices include, for example,consumer electronics devices, business user devices, and machine tomachine devices that benefit from flexible wide area data connectionsand the Internet. Example devices include netbooks, notebooks, mobileInternet devices, personal navigation (e.g., GPS enabled) devices, musicand multimedia players, eReaders, industrial telemetry, automotiveemergency response and diagnostics, 2-way home and industrial powermetering and control, vending machines, parking meters, and many otherdevices. For example, it is highly advantageous to offer service usageand service billing plans for such devices that are more optimal foreach type of device and each type of desired user experience. Toaccomplish this, more sophisticated service usage measuring and serviceusage billing systems are needed as compared to the conventional networkbased techniques in existence today. By providing more flexibility inservice measurement and billing, more advantageous and cost effectiveservice plans can be created for, for example, the new WWAN connecteddevices cited above for all three markets (e.g., consumer, business andmachine to machine) that still maintain the necessary profit margins forthe WWAN carriers to be successful with these various servicebusinesses.

Accordingly, various embodiments disclosed herein provide for a new andflexible augmentation or replacement for existing carrier networkservice usage measurement, service usage accounting, and service usagebilling systems and techniques.

A charging data record (CDR) is a term that as used herein defines aformatted measure of device service usage information, typicallygenerated by one or more network functions that supervise, monitor,and/or control network access for the device. CDRs typically form thebasis for recording device network service usage, and often form thebasis for billing for such usage. Various embodiments are providedherein for device assisted CDR creation, mediation, and billing. Thereare many limitations to the capabilities of service usage recording,aggregation and/or billing when CDRs are generated exclusively bynetwork based functions or equipment. Accordingly, by either augmentingnetwork based service usage measures with device based service usagemeasures, or by replacing network based service usage measures withdevice based service usage measures, it is possible to create a CDRgeneration, aggregation, mediation and/or billing solution that hassuperior or more desirable capabilities/features. While in theory, manyof the service usage measures that can be evaluated on a device can alsobe evaluated in the network data path using various network equipmenttechnologies including but not limited to deep packet inspection (DPI),there are many examples where measuring service usage at the device iseither more desirable or more practical, or in some cases it is the onlyway to obtain the desired measure. Such examples include but are notlimited to the following:

-   -   Application layer service usage measures (e.g., traffic usage        categorized by application or by combinations of application,        destination, and/or content type);    -   Usage measures that do not involve user traffic but instead        involve network overhead traffic (e.g., basic connection        maintenance traffic, signaling traffic, network        logon/AAA/authentication/monitoring traffic, service software        update traffic);    -   Usage that is associated with services that are charged to        another entity other than the end user (e.g., basic network        connection service offer traffic, traffic associated with        providing network access to or downloading service marketing        information, traffic associated with advertiser sponsored        services, traffic associated with content provider sponsored        services, 911 service traffic);    -   Usage measures involving encrypted traffic (e.g., traffic that        is run over encrypted networking protocols or between secure end        points);    -   Implementing service usage measure collection and/or service        usage billing across multiple networks that may have different        and in some cases incompatible, inaccessible (to the CDR system        of record) or incomplete service usage measurement capabilities;    -   Service usage measurement and/or service usage billing        capabilities that are not supported by the present network        gateways, routers, MWC/HLRs, AAA, CDR aggregation, CDR        mediation, billing and/or provisioning systems;    -   New service usage measures and/or new service usage billing        capabilities that are desirable to implement in a manner that        does not require major changes or upgrades to the existing        network gateways, routers, MWC/HLRs, AAA, CDR aggregation, CDR        mediation, billing and/or provisioning systems;    -   New service usage measures and/or new service usage billing        capabilities that are desirable to implement in a manner that        allows for rapid definition and implementation of new service        measures and/or billing plans;    -   New service usage measures and/or new service usage billing        capabilities that are desirable to implement in a manner that        may be implemented in a manner that enables multiple device        group definitions in which each device group gets a customized        programmable definition for service usage collection, accounting        and/or billing;    -   Multi device billing;    -   Multi user billing;    -   Intermediate device billing with single user and multi user with        and without multi device;    -   Content downloads from a specific source to a specific        application with the content being of a specific type or even        identified down to a particular content ID; and/or    -   Various other single event transactions used for billing        purposes.        For these and other reasons, it is desirable to provide a        system/process that utilizes device assisted service usage        measures that provides either an enhancement of existing network        based service usage CDR system capabilities and techniques        and/or a replacement for network based CDR system capabilities        and techniques.

In some embodiments, techniques, such as a system and/or process, thatutilize device assisted service usage measures include one or more ofthe following: (1) receiving a service usage measure from a device incommunication with a wireless network, (2) verifying or protecting thevalidity of the service usage measure, (3) generating a CDR based on theservice usage measure (e.g., device assisted CDR), (4) aggregating CDRs,and (5) mediating the CDR with network CDRs. In some embodiments, thetechniques also include providing a design and provisioning ofdevices/network equipment to recognize the CDRs. In some embodiments,the techniques also include provisioning to recognize that the devicebelongs to a Device Assisted Services (DAS) device group and thatcorresponding CDRs should be accepted and mediated. In some embodiments,the device assisted CDRs are also generated using formats, networkcommunications protocols, network device authentication and/orprovisioning to allow device assisted CDRs into the network CDR system,encryption, and/or signatures as required by the network (e.g., tocomply with network generated CDR requirements or based on any othernetwork and/or service provider requirements and/or standards).

In some embodiments, mediation rules include multi device, multi user,single user devices, and/or intermediate networking devices that can besingle user or multi user, as described herein.

In some embodiments, a device assisted CDR generator collects devicebased service usage measures that are used as the basis for, or as anenhancement (e.g., as a supplement or in addition) to, one or more(e.g., network generated) CDRs that provide one or more networkingfunctions with properly formatted service usage reports that the networkfunction(s) accepts as being transmitted from an authorized source,read, and utilized for helping to determine the service usage of adevice or group of devices. In some embodiments, the network functionsthat the device assisted CDR generator shares CDRs with typicallyinclude one or more of the following: service usage/CDR aggregationand/or mediation servers, gateways, routers, communication nodes, MobileWireless Centers (MWCs, including HLRs), databases, AAA systems, billinginterfaces, and billing systems. For example, the process of CDRcreation in the CDR generator typically includes either using one ormore device based measures of service usage, or one or more device basedmeasures of service usage in combination with one or more network basedmeasures of service usage, possibly processing one or more of suchservice usage measures according to a set of CDR creation, CDRaggregation, and/or CDR mediation rules to arrive at a final deviceusage measure that is, for example, then formatted with the propersyntax, framed, possibly encrypted and/or signed, and encapsulated in acommunication protocol or packet suitable for sharing with networkfunctions. In some embodiments, the CDR generator resides in the device.In some embodiments, the CDR generator resides in a network serverfunction that receives the device assisted service usage measures, alongwith possibly network based usage measures, and then creates a CDR(e.g., in the service controller 122).

In some embodiments, the device assisted CDR generator can reside in theservice processor (e.g., service processor 115), for example, in theservice usage history or billing server functions. In some embodiments,the device assisted CDR generator resides in the device itself, forexample, within the service processor functions, such as the billingagent or the service monitor agent.

There are several factors that are considered in the various embodimentsin order to create a useful, reliable, and secure device assisted CDRsystem, including, for example, but not limited to:

-   -   Identification of each device based service usage measure with        one or more usage transaction codes;    -   Verification of the device based usage measure(s);    -   Secure communication of the device based usage measures to the        network;    -   Efficient (e.g., low bandwidth) communication of the device        based service usage measure;    -   Coordination/comparison/aggregation of the device based service        usage measure with network based service usage measure(s);    -   Formatting the device based service usage measure into a CDR        that can be properly communicated to the network functions        and/or equipment that process service usage information;    -   Causing the network based functions and/or equipment used for        CDR collection, aggregation, mediation and/or billing to        recognize, authorize, and accept communications and CDRs from        the device assisted CDR generator, reading and properly        implementing the correct network session context for the CDR so        that the CDR is properly associated with the correct        device/user/session;    -   Implementing the CDR aggregation rules that determine how to        collect and aggregate the device assisted CDRs as they are        reported through the network CDR system hierarchy;    -   Implementing the mediation rules that determine how the various        device based service usage transaction code measures are        combined and mediated with the other device based service usage        transaction code measures to result in consistent service usage        information for each of the transaction code categories        maintained in the network;    -   Implementing the mediation rules that determine how the device        assisted CDRs are combined and mediated with network based CDRs        to result in consistent service usage information for each of        the transaction code categories maintained in the network;    -   Implementing mediation rules to reconcile the variances between        network based CDR usage measures and device assisted CDR usage        measures;    -   Classification of one or more device groups, with each group        having the capability to uniquely define the service usage        collection, accounting, and/or billing rules;    -   Collecting CDRs generated on networks other than the home        network so that service usage may be measured, accounted for,        and/or billed for across multiple networks;    -   Multi device billing;    -   Multi user billing; and/or    -   Intermediate device billing with single user and multi user with        and without multi device.

In some embodiments, verification of the relative accuracy of the deviceassisted service usage measure is provided. Given that, for example, theservice usage measure is often being generated on an end user device ora device that is readily physically accessed by the general public orother non-secure personnel from a network management viewpoint, in someembodiments, the device agents used in one or more of the serviceprocessor 115 agents are protected from hacking, spoofing, and/or othermisuse. Various techniques are provided herein for protecting theintegrity of the agents used for generating the device assisted serviceusage measures.

In some embodiments, the service usage measures are verified by networkbased cross checks using various techniques. For example, network basedcross checks can provide valuable verification techniques, because, forexample, it is generally not possible or at least very difficult todefeat well designed network based cross checks using varioustechniques, such as those described herein, even if, for example, themeasures used to protect the device agents are defeated or if no deviceprotection measures are employed. In some embodiments, network basedcross checks used to verify the device assisted service usage measuresinclude comparing network based service usage measures (e.g. CDRsgenerated by service usage measurement apparatus in the networkequipment, such as the BTS/BSCs 125, RAN Gateways 410, TransportGateways 420, Mobile Wireless Center/HLRs 132, AAA 121, Service UsageHistory/CDR Aggregation, Mediation, Feed 118, or other networkequipment), sending secure query/response command sequences to theservice processor 115 agent(s) involved in device assisted CDR serviceusage measurement or CDR creation, sending test service usage eventsequences to the device and verifying that the device properly reportedthe service usage, and using various other techniques, such as thosedescribed herein with respect to various embodiments.

In some embodiments, one or more of the following actions are taken ifthe device based service usage measure is found to be in error orinaccurate: bill the user for usage overage or an out of policy device,suspend the device, quarantine the device, SPAN the device, and/orreport the device to a network administration function or person.

In some embodiments, the CDR syntax used to format the device assistedservice usage information into a CDR and/or network communicationprotocols for transmitting CDRs are determined by industry standards(e.g., various versions of 3GPP TS 32.215 format and 3GPP2 TSG-X X.S0011or TIA-835 format). In some embodiments, for a given networkimplementation the network designers will specify modifications of thestandard syntax, formats and/or network communication/transmissionprotocols. In some embodiments, for a given network implementation thenetwork designers will specify syntax, formats, and/or networkcommunication/transmission protocols that are entirely different thanthe standards.

In some embodiments, within the syntax and formatting for the CDR thedevice assisted service usage is typically categorized by a transactioncode. For example, the transaction code can be similar or identical tothe codes in use by network equipment used to generate CDRs, or giventhat the device is capable of generating a much richer set of serviceusage measures, the transaction codes can be a superset of the codesused by network equipment used to generate CDRs (e.g., examples of theusage activities that can be labeled as transaction codes that are morereadily supported by device assisted CDR systems as compared to purelynetwork based CDR systems are provided herein).

In some embodiments, the device sends an identifier for a usage activitytag, an intermediate server determines how to aggregate into CDRtransaction codes and which CDR transaction code to use.

In some embodiments, the device service processor 115 compartmentalizesusage by pre-assigned device activity transaction codes (e.g., these canbe sub-transactions within the main account, transactions within a givenbill-by-account transaction or sub-transactions within a bill-by-accounttransaction). The device implements bill-by-account rules to senddifferent usage reports for each bill-by-account function. In someembodiments, the service controller 122 programs the device to instructit on how to compartmentalize these bill-by-account service usageactivities so that they can be mapped to a transaction code.

In some embodiments, the device reports less compartmentalized serviceusage information and the service controller 122 does the mapping ofservice usage activities to CDR transaction codes, including in somecases bill-by-account codes.

In some embodiments, the CDR sent to 118 or other network equipment, forexample, can include various types of transaction codes including butnot limited to a raw device usage CDR, a bill-by-account (e.g., asub-activity transaction code) CDR, a billing offset CDR, and/or abilling credit CDR. For example, the decision logic (also referred to asbusiness rules or CDR aggregation and mediation rules) that determineshow these various types of CDR transaction codes are to be aggregatedand mediated by the core network and the billing system can be locatedin the network equipment (e.g., a network element, such as service usage118), in the service controller 122, and/or in the billing system 123.

In some embodiments, the device assisted CDR generator uses the deviceassisted service usage measures to generate a CDR that includes serviceusage information, service usage transaction code(s), and, in someembodiments, network information context. In some embodiments, theservice usage information, transaction code, and/or network informationcontext is formatted into communication framing, syntax,encryption/signature, security and/or networking protocols that arecompatible with the formatting used by conventional networking equipmentto generate CDRs. For example, this allows networking equipment used forCDR collection, recording, aggregation, mediation, and/or conversion tobilling records to properly accept, read, and interpret the CDRs thatare generated with the assistance of device based service usagemeasurement. In some embodiments, the device assisted service measuresare provided to an intermediate network server referred to as a servicecontroller (e.g., service controller 122). In some embodiments, theservice controller uses a CDR feed aggregator for a wireless network tocollect device generated usage information for one or more devices onthe wireless network; and provides the device generated usageinformation in a syntax (e.g., charging data record (CDR)), and acommunication protocol (e.g., 3GPP or 3GPP2, or other communicationprotocol(s)) that can be used by the wireless network to augment orreplace network generated usage information for the one or more deviceson the wireless network.

In some embodiments, mediation rules include multi device, multi user,single user devices, intermediate networking devices that can be singleuser or multi user. For example, the device assisted CDRs can beformatted by the device assisted CDR generator to include a transactioncode for one user account, even though the CDRs originate from multipledevices that all belong to the same user. This is an example for amulti-user device assisted CDR billing solution. In another example fora multi-user device assisted CDR billing solution, device assisted CDRsfrom multiple devices and multiple users can all be billed to the sameaccount (e.g., a family plan or a corporate account), but thebill-by-account CDR transaction records can be maintained through thebilling system so that sub-account visibility is provided so that theperson or entity responsible for the main account can obtain visibilityabout which users and/or devices are creating most of the service usagebilling. For example, this type of multi-user, multi-device deviceassisted CDR billing solution can also be used to track types of serviceusage and/or bill for types of service usage that are either impossibleor at least very difficult to account and/or bill for with purelynetwork based CDR systems. In some embodiments, bill-by-account CDRtransaction records can be used to provide sponsored transactionservices, account for network chatter, provide service selectioninterfaces, and other services for multi-user or multi-device serviceplans.

In addition to conventional single user devices (e.g., cell phones,smart phones, netbooks/notebooks, mobile internet devices, personalnavigation devices, music players, electronic eReaders, and other singleuser devices) device assisted service usage measurement and CDRs arealso useful for other types of network capable devices and/or networkingdevices, such as intermediate networking devices (e.g., 3G/4G WWAN toWLAN bridges/routers/gateways, femto cells, DOCSIS modems, DSL modems,remote access/backup routers, and other intermediate network devices).For example, in such devices, particularly with a secure manner toverify that the device assisted service usage measures are relativelyaccurate and/or the device service processor 115 software is notcompromised or hacked, many new service provider service delivery andbilling models can be supported and implemented using the techniquesdescribed herein. For example, in a WiFi to WWAN bridge or router devicemultiple user devices can be supported with the same intermediatenetworking device in a manner that is consistent and compatible with thecentral provider's CDR aggregation and/or billing system by sendingdevice assisted CDRs as described herein that have a service usageand/or billing code referenced to the end user and/or the particularintermediate device.

In some embodiments, the device assisted CDRs generated for theintermediate networking device are associated with a particular end userin which there can be several or many end users using the intermediatenetworking device for networking access, and in some embodiments, witheach end user being required to enter a unique log-in to theintermediate networking device. For example, in this way, all devicesthat connect using WiFi to the intermediate networking device to getWWAN access generate CDRs can either get billed to a particular end userwho is responsible for the master account for that device, or the CDRscan get billed in a secure manner, with verified relative usagemeasurement accuracy to multiple end users from the same intermediatenetworking device. In another example, an end user can have one accountthat allows access to a number of intermediate networking devices, andeach intermediate networking device can generate consistent deviceassisted CDRs with transaction codes for that end user regardless ofwhich intermediate networking device the end user logs in on.

In some embodiments, some of the services provided by the intermediatenetworking device are billed to a specific end user device assisted CDRtransaction code, while other bill-by-account services are billed toother transaction code accounts, such as sponsored partner transactionservice accounts, network chatter accounts, sponsored advertiseraccounts, and/or service sign up accounts. For example, in this manner,various embodiments are provided in which intermediate networkingdevices (e.g., a WWAN to WiFi router/bridge) can sold to one user butcan service and be used to bill other users (e.g., and this can becovered in the first purchasing user's service terms perhaps in exchangefor a discount), or such intermediate networking devices can be locatedwherever access is desired without concern that the device will behacked into so that services can be acquired without charge.

In some embodiments, various types of service usage transactions arebilled for on the intermediate networking device, to any of one or moreusers, in which the information required to bill for such services isnot available to the central provider or MVNO network equipment, just asis the case with, for example, conventional single user devices. In viewof the various embodiments and techniques described herein, thoseskilled in the art will appreciate that similar service models areequally applicable not just to WWAN to WiFi intermediate networkingdevices, but also to the Femto Cell, remote access router, DOCSIS, DSLand other intermediate WWAN to WiFi networking devices.

FIG. 1 illustrates a wireless network architecture for providing deviceassisted CDR creation, aggregation, mediation and billing in accordancewith some embodiments. As shown, FIG. 1 includes a 4G/3G/2G wirelessnetwork operated by, for example, a central provider. As shown, variouswireless devices 100 are in communication with base stations 125 forwireless network communication with the wireless network, and otherdevices 100 are in communication with Wi-Fi Access Points (APs) or Mesh702 for wireless communication to Wi-Fi Access CPE 704 in communicationwith central provider access network 109. In some embodiments, each ofthe wireless devices 100 includes a service processor 115 (as shown),and each service processor connects through a secure control plane linkto a service controller 122. In some embodiments, the network basedservice usage information (e.g., CDRs) is obtained from one or morenetwork elements. As shown, an MVNO core network 210 also includes a CDRstorage, aggregation, mediation, feed 118, a MVNO billing interface 122,and a MVNO billing system 123 (and other network elements as shown inFIG. 1).

As shown in FIG. 1, a CDR storage, aggregation, mediation, feed 118(e.g., service usage 118, including a billing aggregation data store andrules engine) is a functional descriptor for, in some embodiments, adevice/network level service usage information collection, aggregation,mediation, and reporting function located in one or more of thenetworking equipment components attached to one or more of thesub-networks shown in FIG. 1 (e.g., central provider access network 109and/or central provider core network 110), which is in communicationwith the service controller 122, and a central billing interface 127. Asshown in FIG. 1, service usage 118 is shown as a function incommunication with the central provider core network 110. In someembodiments, the CDR storage, aggregation, mediation, feed 118 functionis located elsewhere in the network or partially located in elsewhere orintegrated with as part of other network elements. In some embodiments,CDR storage, aggregation, mediation, feed 118 functionality is locatedor partially located in the AAA server 121 and/or the mobile wirelesscenter/Home Location Register(HLR) 132 (as shown, in communication witha DNS/DHCP server 126). In some embodiments, service usage 118functionality is located or partially located in the base station, basestation controller and/or base station aggregator, collectively referredto as base station 125 in FIG. 1. In some embodiments, CDR storage,aggregation, mediation, feed 118 functionality is located or partiallylocated in a networking component in the central provider access network109, a networking component in the core network 110, the central billingsystem 123, the central billing interface 127, and/or in another networkcomponent or function. This discussion on the possible locations for thenetwork based and device based service usage information collection,aggregation, mediation, and reporting function (e.g., CDR storage,aggregation, mediation, feed 118) can be easily generalized as describedherein and as shown in the other figures described herein by one ofordinary skill in the art. Also as shown in FIG. 1, the servicecontroller 122 is in communication with the central billing interface123 (also sometimes referred to as the external billing managementinterface or billing communication interface) 127, which is incommunication with the central billing system 123. As shown, an ordermanagement 180 and subscriber management 182 are also in communicationwith the central provider core network 110 for facilitating order andsubscriber management of services for the devices 100 in accordance withsome embodiments.

In some embodiments, the CDR storage, aggregation, mediation, feed 118(and/or other network elements or combinations of network elements)provides a device/network level service usage information collection,aggregation, mediation, and reporting function. In some embodiments, theCDR storage, aggregation, mediation, feed 118 (and/or other networkelements or combinations of network elements) collects device generatedusage information for one or more devices on the wireless network (e.g.,devices 100); and provides the device generated usage information in asyntax and a communication protocol that can be used by the wirelessnetwork to augment or replace network generated usage information forthe one or more devices on the wireless network. In some embodiments,the syntax is a charging data record (CDR), and the communicationprotocol is selected from one or more of the following: 3GPP, 3GPP2, orother communication protocols. In some embodiments, the CDR storage,aggregation, mediation, feed 118 (and/or other network elements orcombinations of network elements) includes a service usage data store(e.g., a billing aggregator) and a rules engine for aggregating thecollected device generated usage information. In some embodiments, thesyntax is a charging data record (CDR), and the network device is a CDRfeed aggregator, and the CDR storage, aggregation, mediation, feed 118(and/or other network elements or combinations of network elements) alsoaggregates CDRs for the one or more devices on the wireless network;applies a set of rules to the aggregated CDRs using a rules engine(e.g., bill by account, transactional billing, and/or any other billingor other rules for service usage information collection, aggregation,mediation, and reporting), and communicates a new set of CDRs for theone or more devices on the wireless network to a billing interface or abilling system (e.g., providing a CDR with a billing offset byaccount/service). In some embodiments, the CDR storage, aggregation,mediation, feed 118 (and/or other network elements or combinations ofnetwork elements) communicates a new set of CDRs for the one or moredevices on the wireless network to a billing interface or a billingsystem. In some embodiments, the CDR storage, aggregation, mediation,feed 118 (and/or other network elements or combinations of networkelements) communicates with a service controller to collect the devicegenerated usage information for the one or more devices on the wirelessnetwork. In some embodiments, the CDR storage, aggregation, mediation,feed 118 (and/or other network elements or combinations of networkelements) communicates with a service controller, in which the servicecontroller is in communication with a billing interface or a billingsystem. In some embodiments, the CDR storage, aggregation, mediation,feed 118 (and/or other network elements or combinations of networkelements) communicates the device generated usage information to abilling interface or a billing system. In some embodiments, the CDRstorage, aggregation, mediation, feed (and/or other network elements orcombinations of network elements) communicates with a transport gatewayand/or a Radio Access Network (RAN) gateway to collect the networkgenerated usage information for the one or more devices on the wirelessnetwork. In some embodiments, the service controller 122 communicatesthe device generated service usage information to the CDR storage,aggregation, mediation, feed 118 (and/or other network elements orcombinations of network elements).

In some embodiments, the CDR storage, aggregation, mediation, feed 118(and/or other network elements or combinations of network elements)performs rules for performing a bill by account aggregation andmediation function. In some embodiments, the service controller 122 incommunication with the CDR storage, aggregation, mediation, feed 118(and/or other network elements or combinations of network elements)performs a rules engine for aggregating and mediating the devicegenerated usage information. In some embodiments, a rules engine devicein communication with the CDR storage, aggregation, mediation, feed 118(and/or other network elements or combinations of network elements)performs a rules engine for aggregating and mediating the devicegenerated usage information.

In some embodiments, the rules engine is included in (e.g., integratedwith/part of) the CDR storage, aggregation, mediation, feed 118. In someembodiments, the rules engine and associated functions, as describedherein, is a separate function/device. In some embodiments, the servicecontroller 122 performs some or all of these rules engine basedfunctions, as described herein, and communicates with the centralbilling interface 127. In some embodiments, the service controller 122performs some or all of these rules engine based functions, as describedherein, and communicates with the central billing system 123.

In some embodiments, duplicate CDRs are sent from the network equipmentto the billing system 123 that is used for generating service billing.In some embodiments, duplicate CDRs are filtered to send only thoseCDRs/records for devices controlled by the service controller and/orservice processor (e.g., the managed devices). For example, thisapproach can provide for the same level of reporting, lower level ofreporting, and/or higher level of reporting as compared to the reportingrequired by the central billing system 123.

In some embodiments, a bill-by-account billing offset is provided. Forexample, bill-by-account billing offset information can be informed tothe central billing system 123 by providing a CDR aggregator feed thataggregates the device based service usage data feed to provide a new setof CDRs for the managed devices to the central billing interface 127and/or the central billing system 123. In some embodiments, transactionbilling is provided using similar techniques. For example, transactionbilling log information can be provided to the central billing interface127 and/or the central billing system 123.

In some embodiments, the rules engine (e.g., performed by the serviceusage 118 or another network element, as described herein) provides abill-by-account billing offset. For example, device generated usageinformation (e.g., charging data records (CDRs)) includes a transactiontype field (e.g., indicating a type of service for the associatedservice usage information). The rules engine can apply a rule or a setof rules based on the identified service associated with the devicegenerated usage information to determine a bill-by-account billingoffset (e.g., a new CDR can be generated to provide the determinedbill-by-account billing offset). In some examples, the determinedbill-by-account billing offset can be provided as a credit to the user'sservice usage account (e.g., a new CDR can be generated with a negativeoffset for the user's service usage account, such as for network chatterservice usage, or transactional service usage, or for any other purposesbased on one or more rules performed by the rules engine).

As another example, for a transactional service, a first new CDR can begenerated with a negative offset for the user's service usage accountfor that transactional service related usage, and a second new CDR canbe generated with a positive service usage value to charge that sameservice usage to the transactional service provider (e.g., Amazon, eBay,or another transactional service provider). In some embodiments, theservice controller 122 generates these two new CDRs, and the serviceusage 118 stores, aggregates, and communicates these two new CDRs to thecentral billing interface 127. In some embodiments, the servicecontroller 122 generates these two new CDRs, and the service usage 118stores, aggregates, and communicates these two new CDRs to the centralbilling interface 127, in which the central billing interface 127applies rules (e.g., performs the rules engine for determining thebill-by-account billing offset).

In some embodiments, the service controller 122 sends the devicegenerated CDRs to the rules engine (e.g., service usage 118), and therules engine applies one or more rules, such as those described hereinand/or any other billing/service usage related rules as would beapparent to one of ordinary skill in the art. In some embodiments, theservice controller 122 generates CDRs similar to other network elements,and the rules (e.g., bill-by-account) are performed in the centralbilling interface 127. For example, for the service controller 122 togenerate CDRs similar to other network elements, in some embodiments,the service controller 122 is provisioned on the wireless network andbehaves substantially similar to other CDR generators on the network) aswould be apparent to one of ordinary skill in the art.

In some embodiments, the service controller 122 is provisioned as a newtype of networking function that is recognized as a valid and securesource for CDRs by the other necessary elements in the network (e.g.,the Service Usage History/CDR Aggregation and Mediation Server 118). Insome embodiments, in which the network apparatus typically onlyrecognize CDRs from certain types of networking equipment (e.g., RANGateway 410 or Transport Gateway 420 (as shown in FIG. 3)), then theService Controller 122 can provide authentication credentials to theother networking equipment that indicate it is one of the approved typesof equipment (e.g., for purposes of generating/providing CDRs). In someembodiments, the link between the Service Controller 122 and thenecessary CDR aggregation and mediation equipment is secured,authenticated, encrypted and/or signed.

In some embodiments, the CDR storage, aggregation, mediation, feed 118discards the network based service usage information (e.g., networkbased CDRs) received from one or more network elements. In theseembodiments, the service controller 122 can provide the device basedservice usage information (e.g., device based CDRs) to the CDR storage,aggregation, mediation, feed 118 (e.g., the CDR storage, aggregation,mediation, feed 118 can just provide a store, aggregate, andcommunication function(s)), and the device based service usageinformation is provided to the central billing interface 127 or thecentral billing system 123.

In some embodiments, the device based CDRs and/or new CDRs generatedbased on execution of a rules engine as described herein is providedonly for devices that are managed and/or based on device group, serviceplan, or any other criteria, categorization, and/or grouping.

FIG. 2 illustrates another wireless network architecture for providingdevice assisted CDR creation, aggregation, mediation and billing inaccordance with some embodiments. As shown in FIG. 2, some devices 100are in communication with DOCSIS Head End 125 and some devices 100 arein communication with DSLAM 125, which are in communication with thecentral provider access network 109.

FIG. 3 illustrates another wireless network architecture for providingdevice assisted CDR creation, aggregation, mediation and billing inaccordance with some embodiments. Referring now to the 4G/3G/2G accessnetwork as shown in FIG. 3, the 4G/3G and 3G/2G base stations/nodes 125are in communication with a 4G/3G/2G Radio Access Network (RAN) gateway410 via a radio access network 405, which are in communication with a4G/3G/2G transport gateway 420 via an access transport network 415. Thecentral provider core network 110 is in network communication with theaccess transport network 415 (e.g., via a dedicated/leased line, and asshown, via a firewall 124). The Internet 120 is available via a firewall124 and the transport gateway(s) 420, as shown. Also, as shown, anetwork apparatus provisioning system 160, order management 180, andsubscriber management 182 are in communication with the central providercore network 110. As shown, a AAA server 121, a mobile wirelesscenter/Home Location Register(HLR) 132, a DNS/DHCP 126, and CDR storage,aggregation, mediation, feed 118 are also in communication with theaccess transport network 415. The central billing system 123 and thecentral billing interface 127 are shown in communication with thecentral provider core network 110.

As shown, FIG. 3 includes a 4G/3G/2G wireless network operated by, forexample, a central provider. In some embodiments, each of the wirelessdevices 100 includes a service processor 115 (as shown), and eachservice processor connects through a secure control plane link to aservice controller 122. In some embodiments, the network based serviceusage information (e.g., network generated CDRs) is obtained from RadioAccess Network (RAN) gateway(s) 410 and/or transport gateway(s) 420. Insome embodiments, device based service usage information (e.g., deviceassisted CDRs) are generated by the service processor 115 and/or servicecontroller 122 for some or all of the wireless devices 100 using similartechniques as described herein, and in some embodiments, such devicebased service usage information (e.g., device assisted CDRs) is sent tothe CDR storage, aggregation, mediation, feed 118 (e.g., the CDRstorage, aggregation, mediation, feed 118 can just provide a store,aggregate, and communication function(s)), and/or to the central billinginterface 127 or the central billing system 123, as similarly describedherein with respect to various embodiments.

FIG. 4 illustrates provisioning of a wireless network for providingdevice assisted CDR creation, aggregation, mediation and billing inaccordance with some embodiments. As shown in FIG. 4, the provisioningof various network equipment is provided as shown to recognize eachother as an authorized source of CDRs (e.g., this can be done manuallyor in an automated manner). For example, order management 180,subscriber management, billing interface 127, billing system 123,network provisioning system 160, service controller 122, access networkAAA server 121, mobile wireless center 132, and CDR storage,aggregation, mediation feed 118 communicate with each other for suchprovisioning, which can be implemented using various techniques. In someembodiments, the various network elements are provisioned to recognizedevice assisted CDRs being generated by the service controller 122,which, for example, can be provided to the billing interface 127 and/orthe billing system 123. In some embodiments, network generated CDRs areprovided by RAN/Access gateway 410, aggregation/transport gateway 425,and/or base station controller 125. In some embodiments, other networkelements generate/receive/store device assisted CDRs.

In some embodiments, provisioning of various network equipment isprovided to recognize a given device as belonging to a device group thatsupports a service usage and/or billing plan that relies upon and/orutilizes device assisted CDRs.

In some embodiments, the CDR formats, transaction codes, and CDRtransmission destinations are programmed for each device that generatesCDRs, including the service controller 122 (e.g., in some embodiments,the service controller 122 is the intermediary for CDRs) and/or serviceprocessor 115 (e.g., in some embodiments, the device sends CDRs tonetwork CDR aggregation or billing interface 127/billing system 123 withno intermediate server function).

FIG. 5 illustrates a network architecture for providing device assistedCDRs in accordance with some embodiments. As shown, network generatedCDRs are sent from various network elements to the CDR storage,aggregation, mediation, feed 118 and the service controller 122, asshown in dashed lines with arrows in FIG. 5. In some embodiments, thenetwork generated CDRs are used for verification of device assistedservice (DAS) usage and/or billing information. In some embodiments, thenetwork generated CDRs are provided to the service controller 122, andthe service controller 122 implements aggregation and/or mediation rulesto examine and, in some cases, aggregate and/or mediate networkgenerated/based CDRs with device assisted/based CDRs.

In some embodiments, device assisted CDRs are sent from the servicecontroller 122 to CDR storage, aggregation, mediation, feed 118 andcommunicated to the billing system 123, as shown in solid lines witharrows in FIG. 5. In some embodiments, CDR storage, aggregation,mediation, feed 118 uses DAS service usage CDRs to augment networkgenerated/based CDRs with bill-by-account transaction codes (e.g., assimilarly described herein). In some embodiments, CDR storage,aggregation, mediation, feed 118 implements aggregation and/or mediationrules to account for DAS CDR usage amount in a new bill-by-accounttransaction code and removes the same service usage amount from the bulkdevice account transaction code. In some embodiments, a first DAS CDR issent for the new bill by account transaction code, and a second DAS CDRis sent to be used as a correction (credit) to the main device usageaccount transaction code, and CDR storage, aggregation, mediation, feed118 implements the rules to perform this mediation. In some embodiments,a first DAS CDR is used for a given bill-by-account transaction code,and a second DAS CDR is used as the main device account transactioncode, in which the service controller 122 (or device) has alreadyimplemented the mediation rules so that CDR storage, aggregation,mediation, feed 118 simply passes such DAS CDRs to billing afteraggregating them.

FIG. 6 illustrates another network architecture for providing deviceassisted CDRs in accordance with some embodiments. FIG. 6 also shows thecommunication of device assisted CDRs and network generated CDRs usingsolid and dashed lines with arrows, respectively. As shown, in someembodiments, CDR storage, aggregation, mediation, feed 118 sends networkbased CDRs to service controller 122 for various purposes, such as thosepreviously described herein.

In some embodiments, service controller 122 sends DAS CDRs to billingfor various uses by the billing system 123. In some embodiments, thebilling system 123 uses DAS service usage CDRs to augment network basedCDRs with bill-by-account transaction codes. In some embodiments, thebilling system 123 implements aggregation and/or mediation rules toaccount for DAS CDR usage amount in a new bill-by-account transactioncode and removes the same service usage amount from the bulk deviceaccount transaction code. In some embodiments, a first DAS CDR is sentfor the new bill by account transaction code, and a second DAS CDR issent to be used as a correction (credit) to the main device usageaccount transaction code, and the billing system 123 implements therules to perform this mediation. In some embodiments, a first DAS CDR isused for a given bill-by-account transaction code, and a second is usedas the main device account transaction code, in which the servicecontroller 122 (or device) has already implemented the mediation rulesso that the billing system 123 simply passes such DAS CDRs afteraggregating them.

FIG. 7 illustrates another network architecture for providing deviceassisted CDRs in accordance with some embodiments. FIG. 7 also shows thecommunication of device assisted CDRs and network generated CDRs usingsolid and dashed lines with arrows, respectively. FIG. 7 is similar toFIG. 6, except as shown in FIG. 7, service usage information is passedthrough the billing interface 127 instead of the billing CDR aggregationinterface. For example, the service usage detailed bill-by-accountinformation and offset (credit) information can be formatted as a CDR orcan be formatted in a higher level syntax as required by the billinginterface 127.

FIG. 8 illustrates another network architecture for providing deviceassisted CDRs in accordance with some embodiments. FIG. 8 also shows thecommunication of device assisted CDRs and network generated CDRs usingsolid and dashed lines with arrows, respectively. In some embodiments,as shown in FIG. 8, the central provider need not modify the existingCDR storage, aggregation, mediation, feed 118, so the additionalaggregation and mediation rules discussed above with respect to FIG. 5are implemented as a new layer of rules in a new network function, shownas secondary DAS CDR aggregation mediation 118A, that is located betweenthe billing system and the CDR storage, aggregation, mediation, feed118. For example, this new network function (e.g., secondary DAS CDRaggregation mediation 118A) can reside in the network (as shown) or inthe service processor 115, in the service controller 122, or elsewherein the network or on the device.

FIG. 9 is a functional diagram illustrating a device based serviceprocessor 115 and a service controller 122 in accordance with someembodiments. For example, this provides relatively full featured devicebased service processor implementation and service controllerimplementation. As shown, this corresponds to a networking configurationin which the service controller 122 is connected to the Internet 120 andnot directly to the access network 1610. As shown, a data plane (e.g.,service traffic plane) communication path is shown in solid lineconnections and control plane (e.g., service control plane)communication path is shown in dashed line connections. As will beapparent, the division in functionality between one device agent andanother is based on, for example, design choices, networkingenvironments, devices and/or services/applications, and variousdifferent combinations can be used in various different implementations.For example, the functional lines can be re-drawn in any way that theproduct designers see fit. As shown, this includes certain divisions andfunctional breakouts for device agents as an illustrativeimplementation, although other, potentially more complex, embodimentscan include different divisions and functional breakouts for deviceagent functionality specifications, for example, in order to managedevelopment specification and testing complexity and workflow. Inaddition, the placement of the agents that operate, interact with ormonitor the data path can be moved or re-ordered in various embodiments.For example, the functional elements shown in FIG. 9 are described belowwith respect to FIGS. 10 and 11.

As shown in FIG. 9, service processor 115 includes a service controldevice link 1691. For example, as device based service controltechniques involving supervision across a network become moresophisticated, it becomes increasingly important to have an efficientand flexible control plane communication link between the device agentsand the network elements communicating with, controlling, monitoring, orverifying service policy. In some embodiments, the service controldevice link 1691 provides the device side of a system for transmissionand reception of service agent to/from network element functions. Insome embodiments, the traffic efficiency of this link is enhanced bybuffering and framing multiple agent messages in the transmissions. Insome embodiments, the traffic efficiency is further improved bycontrolling the transmission frequency or linking the transmissionfrequency to the rate of service usage or traffic usage. In someembodiments, one or more levels of security or encryption are used tomake the link robust to discovery, eavesdropping or compromise. In someembodiments, the service control device link 1691 also provides thecommunications link and heartbeat timing for the agent heartbeatfunction. As discussed below, various embodiments disclosed herein forthe service control device link 1691 provide an efficient and securesolution for transmitting and receiving service policy implementation,control, monitoring and verification information with other networkelements.

As shown in FIG. 9, the service controller 122 includes a servicecontrol server link 1638. In some embodiments, device based servicecontrol techniques involving supervision across a network (e.g., on thecontrol plane) are more sophisticated, and for such it is increasinglyimportant to have an efficient and flexible control plane communicationlink between the device agents (e.g., of the service processor 115) andthe network elements (e.g., of the service controller 122) communicatingwith, controlling, monitoring, or verifying service policy. For example,the communication link between the service control server link 1638 ofservice controller 122 and the service control device link 1691 of theservice processor 115 can provide an efficient and flexible controlplane communication link, a service control link 1653 as shown in FIG.9, and, in some embodiments, this control plane communication linkprovides for a secure (e.g., encrypted) communications link forproviding secure, bidirectional communications between the serviceprocessor 115 and the service controller 122. In some embodiments, theservice control server link 1638 provides the network side of a systemfor transmission and reception of service agent to/from network elementfunctions. In some embodiments, the traffic efficiency of this link isenhanced by buffering and framing multiple agent messages in thetransmissions (e.g., thereby reducing network chatter). In someembodiments, the traffic efficiency is further improved by controllingthe transmission frequency and/or linking the transmission frequency tothe rate of service usage or traffic usage. In some embodiments, one ormore levels of security and/or encryption are used to secure the linkagainst potential discovery, eavesdropping or compromise ofcommunications on the link. In some embodiments, the service controlserver link 1638 also provides the communications link and heartbeattiming for the agent heartbeat function.

In some embodiments, the service control server link 1638 provides forsecuring, signing, encrypting and/or otherwise protecting thecommunications before sending such communications over the servicecontrol link 1653. For example, the service control server link 1638 cansend to the transport layer or directly to the link layer fortransmission. In another example, the service control server link 1638further secures the communications with transport layer encryption, suchas TCP TLS SSH version 1 or 2 or another secure transport layerprotocol. As another example, the service control server link 1638 canencrypt at the link layer, such as using IPSEC, various possible VPNservices, other forms of IP layer encryption and/or another link layerencryption technique.

As shown in FIG. 9, the service controller 122 includes an accesscontrol integrity server 1654. In some embodiments, the access controlintegrity server 1654 collects device information on service policy,service usage, agent configuration and/or agent behavior. For example,the access control integrity server 1654 can cross check thisinformation to identify integrity breaches in the service policyimplementation and control system. In another example, the accesscontrol integrity server 1654 can initiate action when a service policyviolation or a system integrity breach is suspected.

In some embodiments, the access control integrity server 1654 (and/orsome other agent of service controller 122) acts on access controlintegrity agent 1694 reports and error conditions. Many of the accesscontrol integrity agent 1654 checks can be accomplished by the server.For example, the access control integrity agent 1654 checks include oneor more of the following: service usage measure against usage rangeconsistent with policies (e.g., usage measure from the network and/orfrom the device); configuration of agents; operation of the agents;and/or dynamic agent download.

In some embodiments, the access control integrity server 1654 (and/orsome other agent of service controller 122) verifies device servicepolicy implementations by comparing various service usage measures(e.g., based on network monitored information, such as by using IPDRs orCDRs, and/or local service usage monitoring information) againstexpected service usage behavior given the policies that are intended tobe in place. For example, device service policy implementations caninclude measuring total data passed, data passed in a period of time, IPaddresses, data per IP address, and/or other measures such as location,downloads, email accessed, URLs, and comparing such measures expectedservice usage behavior given the policies that are intended to be inplace.

In some embodiments, the access control integrity server 1654 (and/orsome other agent of service controller 122) verifies device servicepolicy, and the verification error conditions that can indicate amismatch in service measure and service policy include one or more ofthe following: unauthorized network access (e.g., access beyond ambientservice policy limits); unauthorized network speed (e.g., average speedbeyond service policy limit); network data amount does not match policylimit (e.g., device not stop at limit without re-up/revising servicepolicy); unauthorized network address; unauthorized service usage (e.g.,VOIP, email, and/or web browsing); unauthorized application usage (e.g.,email, VOIP, email, and/or web); service usage rate too high for plan,and policy controller not controlling/throttling it down; and/or anyother mismatch in service measure and service policy. Accordingly, insome embodiments, the access control integrity server 1654 (and/or someother agent of service controller 122) provides a policy/service controlintegrity service to continually (e.g., periodically and/or based ontrigger events) verify that the service control of the device has notbeen compromised and/or is not behaving out of policy.

As shown in FIG. 9, service controller 122 includes a service historyserver 1650. In some embodiments, the service history server 1650collects and records service usage or service activity reports from theAccess Network AAA Server 1621 and the Service Monitor Agent 1696. Forexample, although service usage history from the network elements can incertain embodiments be less detailed than service history from thedevice, the service history from the network can provide a valuablesource for verification of device service policy implementation,because, for example, it is extremely difficult for a device error orcompromise event on the device to compromise the network based equipmentand software. For example, service history reports from the device caninclude various service tracking information, as similarly describedabove. In some embodiments, the service history server 1650 provides theservice history on request to other servers and/or one or more agents.In some embodiments, the service history server 1650 provides theservice usage history to the device service history 1618. In someembodiments, for purposes of facilitating the activation trackingservice functions (described below), the service history server 1650maintains a history of which networks the device has connected to. Forexample, this network activity summary can include a summary of thenetworks accessed, activity versus time per connection, and/or trafficversus time per connection. As another example, this activity summarycan further be analyzed or reported to estimate the type of service planassociated with the traffic activity for the purpose of bill sharingreconciliation.

As shown in FIG. 9, service controller 122 includes a policy managementserver 1652. In some embodiments, the policy management server 1652transmits policies to the service processor 115 via the service controllink 1653. In some embodiments, the policy management server 1652manages policy settings on the device (e.g., various policy settings asdescribed herein with respect to various embodiments) in accordance witha device service profile. In some embodiments, the policy managementserver 1652 sets instantaneous policies on policy implementation agents(e.g., policy implementation agent 1690). For example, the policymanagement server 1652 can issue policy settings, monitor service usageand, if necessary, modify policy settings. For example, in the case of auser who prefers for the network to manage their service usage costs, orin the case of any adaptive policy management needs, the policymanagement server 1652 can maintain a relatively high frequency ofcommunication with the device to collect traffic and/or service measuresand issue new policy settings. In this example, device monitored servicemeasures and any user service policy preference changes are reported,periodically and/or based on various triggers/events/requests, to thepolicy management server 1652. In this example, user privacy settingsgenerally require secure communication with the network (e.g., a secureservice control link 1653), such as with the policy management server1652, to ensure that various aspects of user privacy are properlymaintained during such configuration requests/policy settingstransmitted over the network. For example, information can becompartmentalized to service policy management and not communicated toother databases used for CRM for maintaining user privacy.

In some embodiments, the policy management server 1652 provides adaptivepolicy management on the device. For example, the policy managementserver 1652 can issue policy settings and objectives and rely on thedevice based policy management (e.g., service processor 115) for some orall of the policy adaptation. This approach can require less interactionwith the device thereby reducing network chatter on service control link1653 for purposes of device policy management (e.g., network chatter isreduced relative to various server/network based policy managementapproaches described above). This approach can also provide robust userprivacy embodiments by allowing the user to configure the device policyfor user privacy preferences/settings so that, for example, sensitiveinformation (e.g., geo-location data, website history) is notcommunicated to the network without the user's approval. In someembodiments, the policy management server 1652 adjusts service policybased on time of day. In some embodiments, the policy management server1652 receives, requests or otherwise obtains a measure of networkavailability and adjusts traffic shaping policy and/or other policysettings based on available network capacity.

As shown in FIG. 9, service controller 122 includes a network trafficanalysis server 1656. In some embodiments, the network traffic analysisserver 1656 collects/receives service usage history for devices and/orgroups of devices and analyzes the service usage. In some embodiments,the network traffic analysis server 1656 presents service usagestatistics in various formats to identify improvements in networkservice quality and/or service profitability. In other embodiments, thenetwork traffic analysis server 1656 estimates the service qualityand/or service usage for the network under variable settings onpotential service policy. In other embodiments, the network trafficanalysis server 1656 identifies actual or potential service behaviors byone or more devices that are causing problems for overall networkservice quality or service cost.

As shown in FIG. 9, service controller 122 includes a beta test server1658. In some embodiments, the beta test server 1658 publishes candidateservice plan policy settings to one or more devices. In someembodiments, the beta test server 1658 provides summary reports ofnetwork service usage or user feedback information for one or morecandidate service plan policy settings. In some embodiments, the betatest server 1658 provides a mechanism to compare the beta test resultsfor different candidate service plan policy settings or select theoptimum candidates for further policy settings optimization.

As shown in FIG. 9, service controller 122 includes a service downloadcontrol server 1660. In some embodiments, the service download controlserver 1660 provides a download function to install and/or updateservice software elements (e.g., the service processor 115 and/oragents/components of the service processor 115) on the device, asdescribed herein.

As shown in FIG. 9 service controller 122 includes a billing eventserver 1662. In some embodiments, the billing event server 1662 collectsbilling events, provides service plan information to the serviceprocessor 115, provides service usage updates to the service processor115, serves as interface between device and central billing server 1619,and/or provides trusted third party function for certain ecommercebilling transactions.

As shown in FIG. 9, the Access Network AAA server 1621 is in networkcommunication with the access network 1610. In some embodiments, theAccess Network AAA server 1621 provides the necessary access network AAAservices (e.g., access control and authorization functions for thedevice access layer) to allow the devices onto the central provideraccess network and the service provider network. In some embodiments,another layer of access control is required for the device to gainaccess to other networks, such as the Internet, a corporate networkand/or a machine to machine network. This additional layer of accesscontrol can be implemented, for example, by the service processor 115 onthe device. In some embodiments, the Access Network AAA server 1621 alsoprovides the ability to suspend service for a device and resume servicefor a device based on communications received from the servicecontroller 122. In some embodiments, the Access Network AAA server 1621also provides the ability to direct routing for device traffic to aquarantine network or to restrict or limit network access when a devicequarantine condition is invoked. In some embodiments, the Access NetworkAAA server 1621 also records and reports device network service usage(e.g., device network service usage can be reported to device servicehistory 1618).

As shown in FIG. 9, the device service history 1618 is in networkcommunication with the access network 1610. In some embodiments, thedevice service history 1618 provides service usage data records used forvarious purposes in various embodiments. In some embodiments, the deviceservice history 1618 is used to assist in verifying service policyimplementation. In some embodiments, the device service history 1618 isused to verify service monitoring. In some embodiments, the deviceservice history 1618 is used to verify billing records and/or billingpolicy implementation. In some embodiments, the device service history1618 is used to synchronize and/or verify the local service usagecounter.

As shown in FIG. 9, the central provider billing server 1619 is innetwork communication with the access network 1610. In some embodiments,the central provider billing server 1619 provides a mediation functionfor central provider billing events. For example, the central providerbilling server 1619 can accept service plan changes. In someembodiments, the central provider billing server 1619 provides updateson device service usage, service plan limits and/or service policies. Insome embodiments, the central provider billing server 1619 collectsbilling events, formulates bills, bills service users, provides certainbilling event data and service plan information to the servicecontroller 122 and/or device 100.

As shown in FIG. 9, in some embodiments, modem selection and control1811 selects the access network connection and is in communication withthe modem firewall 1655, and modem drivers 1831, 1815, 1814, 1813, 1812convert data traffic into modem bus traffic for one or more modems andare in communication with the modem selection and control 1811. In someembodiments, different profiles are selected based on the selectednetwork connection (e.g., different service profiles/policies for WWAN,WLAN, WPAN, Ethernet and/or DSL network connections), which is alsoreferred to herein as multimode profile setting. For example, serviceprofile settings can be based on the actual access network (e.g., homeDSL/cable or work network) behind the Wi-Fi not the fact that it isWi-Fi (or any other network, such as DSL/cable, satellite, or T-1),which is viewed as different than accessing a Wi-Fi network at thecoffee shop. For example, in a Wi-Fi hotspot situation in which thereare a significant number of users on a DSL or T-1 backhaul, the servicecontroller can sit in a service provider cloud or an MVNO cloud, theservice controls can be provided by a VSP capability offered by theservice provider or the service controller can be owned by the hotspotservice provider that uses the service controller on their own withoutany association with an access network service provider. For example,the service processors can be controlled by the service controller todivide up the available bandwidth at the hotspot according to QoS oruser sharing rules (e.g., with some users having higher differentiatedpriority (potentially for higher service payments) than other users). Asanother example, ambient services (as similarly described herein) can beprovided for the hotspot for verified service processors.

In some embodiments, the service processor 115 and service controller122 are capable of assigning multiple service profiles associated withmultiple service plans that the user chooses individually or incombination as a package. For example, a device 100 starts with ambientservices that include free transaction services wherein the user paysfor transactions or events rather than the basic service (e.g., a newsservice, eReader, PND service, pay as you go session Internet) in whicheach service is supported with a bill by account capability to correctlyaccount for any subsidized partner billing to provide the transactionservices (e.g., Barnes and Noble may pay for the eReader service andoffer a revenue share to the service provider for any book or magazinetransactions purchased from the device 100). In some embodiments, thebill by account service can also track the transactions and, in someembodiments, advertisements for the purpose of revenue sharing, allusing the service monitoring capabilities disclosed herein. Afterinitiating services with the free ambient service discussed above, theuser may later choose a post-pay monthly Internet, email and SMSservice. In this case, the service controller 122 would obtain from thebilling system 123 in the case of network based billing (or in someembodiments the service controller 122 billing event server 1622 in thecase of device based billing) the billing plan code for the newInternet, email and SMS service. In some embodiments, this code is crossreferenced in a database (e.g., the policy management server 1652) tofind the appropriate service profile for the new service in combinationwith the initial ambient service. The new superset service profile isthen applied so that the user maintains free access to the ambientservices, and the billing partners continue to subsidize those services,the user also gets access to Internet services and may choose theservice control profile (e.g., from one of the embodiments disclosedherein). The superset profile is the profile that provides the combinedcapabilities of two or more service profiles when the profiles areapplied to the same device 100 service processor. In some embodiments,the device 100 (service processor 115) can determine the supersetprofile rather than the service controller 122 when more than one“stackable” service is selected by the user or otherwise applied to thedevice. The flexibility of the service processor 115 and servicecontroller 122 embodiments described herein allow for a large variety ofservice profiles to be defined and applied individually or as a supersetto achieve the desired device 100 service features.

As shown in FIG. 9, an agent communication bus 1630 represents afunctional description for providing communication for the variousservice processor 115 agents and functions. In some embodiments, asrepresented in the functional diagram illustrated in FIG. 9, thearchitecture of the bus is generally multipoint to multipoint so thatany agent can communicate with any other agent, the service controlleror in some cases other components of the device, such user interface1697 and/or modem components. As described below, the architecture canalso be point to point for certain agents or communication transactions,or point to multipoint within the agent framework so that all agentcommunication can be concentrated, or secured, or controlled, orrestricted, or logged or reported. In some embodiments, the agentcommunication bus is secured, signed, encrypted, hidden, partitionedand/or otherwise protected from unauthorized monitoring or usage. Insome embodiments, an application interface agent (not shown) is used toliterally tag or virtually tag application layer traffic so that thepolicy implementation agent(s) 1690 has the necessary information toimplement selected traffic shaping solutions. In some embodiments, anapplication interface agent (not shown) is in communication with variousapplications, including a TCP application 1604, an IP application 1605,and a voice application 1602.

In some embodiments, device assisted services (DAS) techniques forproviding an activity map for classifying or categorizing service usageactivities to associate various monitored activities (e.g., by URL, bynetwork domain, by website, by network traffic type, by application orapplication type, and/or any other service usage activitycategorization/classification) with associated IP addresses areprovided. In some embodiments, a policy control agent (not shown),service monitor agent 1696, or another agent or function (orcombinations thereof) of the service processor 115 provides a DASactivity map. In some embodiments, a policy control agent, servicemonitor agent, or another agent or function (or combinations thereof) ofthe service processor provides an activity map for classifying orcategorizing service usage activities to associate various monitoredactivities (e.g., by Uniform Resource Locator (URL), by network domain,by website, by network traffic type, by application or application type,and/or any other service usage activity classification/categorization)with associated IP addresses. In some embodiments, a policy controlagent, service monitor agent, or another agent or function (orcombinations thereof) of the service processor determines the associatedIP addresses for monitored service usage activities using varioustechniques to snoop the DNS request(s) (e.g., by performing suchsnooping techniques on the device 100 the associated IP addresses can bedetermined without the need for a network request for a reverse DNSlookup). In some embodiments, a policy control agent, service monitoragent, or another agent or function (or combinations thereof) of theservice processor records and reports IP addresses or includes a DNSlookup function to report IP addresses or IP addresses and associatedURLs for monitored service usage activities. For example, a policycontrol agent, service monitor agent, or another agent or function (orcombinations thereof) of the service processor can determine theassociated IP addresses for monitored service usage activities usingvarious techniques to perform a DNS lookup function (e.g., using a localDNS cache on the monitored device 100). In some embodiments, one or moreof these techniques are used to dynamically build and maintain a DASactivity map that maps, for example, URLs to IP addresses, applicationsto IP addresses, content types to IP addresses, and/or any othercategorization/classification to IP addresses as applicable. In someembodiments, the DAS activity map is used for various DAS trafficcontrol and/or throttling techniques as described herein with respect tovarious embodiments. In some embodiments, the DAS activity map is usedto provide the user various UI related information and notificationtechniques related to service usage as described herein with respect tovarious embodiments. In some embodiments, the DAS activity map is usedto provide service usage monitoring, prediction/estimation of futureservice usage, service usage billing (e.g., bill by account and/or anyother service usage/billing categorization techniques), DAS techniquesfor ambient services usage monitoring, DAS techniques for generatingmicro-CDRs (e.g., also referred to as service usage partition, serviceusage recording partition, service charging bucket, device generatedCDRs, such as in the case where the device and not a network componentare generating the usage records, ambient usage records, specializedservice usage records, or other terms to indicate a service usage datarecord generated to provide a more refined or detailed breakdown ofservice usage for the device), and/or any of the various other DASrelated techniques as described herein with respect to variousembodiments.

In some embodiments, all or a portion of the service processor 115functions disclosed herein are implemented in software. In someembodiments, all or a portion of the service processor 115 functions areimplemented in hardware. In some embodiments, all or substantially allof the service processor 115 functionality (as discussed herein) isimplemented and stored in software that can be performed on (e.g.,executed by) various components in device 100. In some embodiments, itis advantageous to store or implement certain portions or all of serviceprocessor 115 in protected or secure memory so that other undesiredprograms (and/or unauthorized users) have difficulty accessing thefunctions or software in service processor 115. In some embodiments,service processor 115, at least in part, is implemented in and/or storedon secure non-volatile memory (e.g., non volatile memory can be securenon-volatile memory) that is not accessible without pass keys and/orother security mechanisms. In some embodiments, the ability to load atleast a portion of service processor 115 software into protectednon-volatile memory also requires a secure key and/or signature and/orrequires that the service processor 115 software components being loadedinto non-volatile memory are also securely encrypted and appropriatelysigned by an authority that is trusted by a secure software downloaderfunction, such as service downloader 1663 as shown in FIG. 16. In someembodiments, a secure software download embodiment also uses a securenon-volatile memory. Those of ordinary skill in the art will alsoappreciate that all memory can be on-chip, off-chip, on-board and/oroff-board.

FIG. 10 provides a table summarizing various service processer 115functional elements in accordance with some embodiments. Many of theseagents are similarly described above, and the table shown in FIG. 10 isnot intended to be an exhaustive summary of these agents, nor anexhaustive description of all functions that the agents perform or aredescribed herein, but rather FIG. 10 is provided as a summary aid inunderstanding the basic functions of each agent in accordance with someembodiments and how the agents interact with one another, with theservice controller server elements, and/or with other network functionsin certain embodiments to form a reliable device based service deliverysolution and/or platform.

FIG. 11 provides a table summarizing various service controller 122functional elements in accordance with some embodiments. Many of theseagents/elements are similarly described above, and the table shown inFIG. 11 is not intended to be an exhaustive summary of these serverelements, nor an exhaustive description of all functions that theelements perform or are described herein, but rather FIG. 11 is providedas a summary aid in understanding the basic functions of each element inaccordance with some embodiments and how the elements interact with oneanother, certain network elements, and/or the service processor agentsin certain embodiments to form a reliable device based service deliverysolution and/or platform.

FIG. 12 illustrates a device stack providing various service usagemeasurement from various points in the networking stack for a servicemonitor agent, a billing agent, and an access control integrity agent toassist in verifying the service usage measures and billing reports inaccordance with some embodiments. As shown in FIG. 12, several serviceagents take part in data path operations to achieve various data pathimprovements, and, for example, several other service agents can managethe policy settings for the data path service, implement billing for thedata path service, manage one or more modem selection and settings foraccess network connection, interface with the user and/or provideservice policy implementation verification. Additionally, in someembodiments, several agents perform functions to assist in verifyingthat the service control or monitoring policies intended to be in placeare properly implemented, the service control or monitoring policies arebeing properly adhered to, that the service processor or one or moreservice agents are operating properly, to prevent unintended errors inpolicy implementation or control, and/or to prevent tampering with theservice policies or control. As shown, the service measurement pointslabeled I through VI represent various service measurement points forservice monitor agent 1696 and/or other agents to perform variousservice monitoring activities. Each of these measurement points can havea useful purpose in various embodiments described herein. For example,each of the traffic measurement points that is employed in a givendesign can be used by a monitoring agent to track application layertraffic through the communication stack to assist policy implementationfunctions, such as the policy implementation agent 1690, or in someembodiments the modem firewall agent 1655 or the application interfaceagent, in making a determination regarding the traffic parameters ortype once the traffic is farther down in the communication stack whereit is sometimes difficult or impossible to make a complete determinationof traffic parameters. The particular locations for the measurementpoints provided in these figures are intended as instructional examples,and other measurement points can be used for different embodiments, aswill be apparent to one of ordinary skill in the art in view of theembodiments described herein. Generally, in some embodiments, one ormore measurement points within the device can be used to assist inservice control verification and/or device or service troubleshooting.

In some embodiments, the service monitor agent and/or other agentsimplement virtual traffic tagging by tracking or tracing packet flowsthrough the various communication stack formatting, processing andencryption steps, and providing the virtual tag information to thevarious agents that monitor, control, shape, throttle or otherwiseobserve, manipulate or modify the traffic. This tagging approach isreferred to herein as virtual tagging, because there is not a literaldata flow, traffic flow or packet tag that is attached to flows orpackets, and the book-keeping to tag the packet is done through trackingor tracing the flow or packet through the stack instead. In someembodiments, the application interface and/or other agents identify atraffic flow, associate it with a service usage activity and cause aliteral tag to be attached to the traffic or packets associated with theactivity. This tagging approach is referred to herein as literaltagging. There are various advantages with both the virtual tagging andthe literal tagging approaches. For example, it can be preferable insome embodiments to reduce the inter-agent communication required totrack or trace a packet through the stack processing by assigning aliteral tag so that each flow or packet has its own activity associationembedded in the data. As another example, it can be preferable in someembodiments to re-use portions of standard communication stack softwareor components, enhancing the verifiable traffic control or servicecontrol capabilities of the standard stack by inserting additionalprocessing steps associated with the various service agents andmonitoring points rather than re-writing the entire stack to correctlyprocess literal tagging information, and in such cases, a virtualtagging scheme may be desired. As yet another example, some standardcommunication stacks provide for unused, unspecified or otherwiseavailable bit fields in a packet frame or flow, and these unused,unspecified or otherwise available bit fields can be used to literallytag traffic without the need to re-write all of the standardcommunication stack software, with only the portions of the stack thatare added to enhance the verifiable traffic control or service controlcapabilities of the standard stack needing to decode and use the literaltagging information encapsulated in the available bit fields. In thecase of literal tagging, in some embodiments, the tags are removed priorto passing the packets or flows to the network or to the applicationsutilizing the stack. In some embodiments, the manner in which thevirtual or literal tagging is implemented can be developed into acommunication standard specification so that various device or serviceproduct developers can independently develop the communication stackand/or service processor hardware and/or software in a manner that iscompatible with the service controller specifications and the productsof other device or service product developers.

It will be appreciated that although the implementation/use of any orall of the measurement points illustrated in FIG. 12 is not required tohave an effective implementation, such as was similarly shown withrespect to various embodiments described herein, various embodiments canbenefit from these and/or similar measurement points. It will also beappreciated that the exact measurement points can be moved to differentlocations in the traffic processing stack, just as the variousembodiments described herein can have the agents affecting policyimplementation moved to different points in the traffic processing stackwhile still maintaining effective operation. In some embodiments, one ormore measurement points are provided deeper in the modem stack where,for example, it is more difficult to circumvent and can be moredifficult to access for tampering purposes if the modem is designed withthe proper software and/or hardware security to protect the integrity ofthe modem stack and measurement point(s).

Referring to FIG. 12, describing the device communications stack fromthe bottom to the top of the stack as shown, the device communicationsstack provides a communication layer for each of the modems of thedevice at the bottom of the device communications stack. Examplemeasurement point VI resides within or just above the modem driverlayer. For example, the modem driver performs modem bus communications,data protocol translations, modem control and configuration to interfacethe networking stack traffic to the modem. As shown, measurement pointVI is common to all modem drivers and modems, and it is advantageous forcertain embodiments to differentiate the traffic or service activitytaking place through one modem from that of one or more of the othermodems. In some embodiments, measurement point VI, or anothermeasurement point, is located over, within or below one or more of theindividual modem drivers. The respective modem buses for each modemreside between example measurement points V and VI. In the next higherlayer, a modem selection & control layer for multimode device basedcommunication is provided. In some embodiments, this layer is controlledby a network decision policy that selects the most desirable networkmodem for some or all of the data traffic, and when the most desirablenetwork is not available the policy reverts to the next most desirablenetwork until a connection is established provided that one of thenetworks is available. In some embodiments, certain network traffic,such as verification, control, redundant or secure traffic, is routed toone of the networks even when some or all of the data traffic is routedto another network. This dual routing capability provides for a varietyof enhanced security, enhanced reliability or enhanced manageabilitydevices, services or applications. In the next higher layer, a modemfirewall is provided. For example, the modem firewall provides fortraditional firewall functions, but unlike traditional firewalls, inorder to rely on the firewall for verifiable service usage control, suchas access control and security protection from unwanted networkingtraffic or applications, the various service verification techniques andagents described herein are added to the firewall function to verifycompliance with service policy and prevent tampering of the servicecontrols. In some embodiments, the modem firewall is implemented fartherup the stack, possibly in combination with other layers as indicated inother Figures. In some embodiments, a dedicated firewall function orlayer is provided that is independent of the other processing layers,such as the policy implementation layer, the packet forwarding layerand/or the application layer. In some embodiments, the modem firewall isimplemented farther down the stack, such as within the modem drivers,below the modem drivers, or in the modem itself. Example measurementpoint IV resides between the modem firewall layer and an IP queuing androuting layer. As shown, an IP queuing and routing layer is separatefrom the policy implementation layer where the policy implementationagent implements a portion of the traffic control and/or service usagecontrol policies. As described herein, in some embodiments, thesefunctions are separated so that a standard network stack function can beused for IP queuing and routing, and the modifications necessary toimplement the policy implementation agent functions can be provided in anew layer inserted into the standard stack. In some embodiments, the IPqueuing and routing layer is combined with the traffic or service usagecontrol layer. For example, a combined routing and policy implementationlayer embodiment can also be used with the other embodiments, such asshown in FIG. 12. Measurement point III resides between the IP queuingand routing layer and a policy implementation agent layer. Measurementpoint II resides between the policy implementation agent layer and thetransport layer, including TCP, UDP, and other IP as shown. The sessionlayer resides above the transport layer, which is shown as a socketassignment and session management (e.g., basic TCP setup, TLS/SSL)layer. The network services API (e.g., HTTP, HTTPS, FTP (File TransferProtocol), SMTP (Simple Mail Transfer Protocol), POP3, DNS) residesabove the session layer. Measurement point I resides between the networkservices API layer and an application layer, shown as applicationservice interface agent in the device communications stack of FIG. 12.

As shown in FIG. 12, the application service interface layer is abovethe standard networking stack API and, in some embodiments, its functionis to monitor and in some cases intercept and process the trafficbetween the applications and the standard networking stack API. In someembodiments, the application service interface layer identifiesapplication traffic flows before the application traffic flows are moredifficult or practically impossible to identify farther down in thestack. In some embodiments, the application service interface layer inthis way assists application layer tagging in both the virtual andliteral tagging cases. In the case of upstream traffic, the applicationlayer tagging is straight forward, because the traffic originates at theapplication layer. In some downstream embodiments, where the traffic orservice activity classification relies on traffic attributes that arereadily obtainable, such as source address or URL, application socketaddress, IP destination address, time of day or any other readilyobtained parameter, the traffic type can be identified and tagged forprocessing by the firewall agent or another agent as it initiallyarrives. In other embodiments, as described herein, in the downstreamcase, the solution is generally more sophisticated when a trafficparameter that is needed to classify the manner in which the trafficflow is to be controlled or throttled is not readily available at thelower levels of the stack, such as association with an aspect of anapplication, type of content, something contained within TLS, IPSEC orother secure format, or other information associated with the traffic.Accordingly, in some embodiments the networking stack identifies thetraffic flow before it is fully characterized, categorized or associatedwith a service activity, and then passes the traffic through to theapplication interface layer where the final classification is completed.In such embodiments, the application interface layer then communicatesthe traffic flow ID with the proper classification so that after aninitial short traffic burst or time period the policy implementationagents can properly control the traffic. In some embodiments, there isalso a policy for tagging and setting service control policies fortraffic that cannot be fully identified with all sources of taggingincluding application layer tagging.

As shown in FIG. 12, a service monitor agent, which is also incommunication with the agent communication bus 1630, communicates withvarious layers of the device communications stack. For example, theservice monitor agent, performs monitoring at each of measurement pointsI through VI, receiving information including application information,service usage and other service related information, and assignmentinformation. An access control integrity agent is in communication withthe service monitor agent via the agent communications bus 1630, as alsoshown.

FIG. 13 illustrates an embodiment similar to FIG. 12 in which some ofthe service processor is implemented on the modem and some of theservice processor is implemented on the device application processor inaccordance with some embodiments. In some embodiments, a portion of theservice processor is implemented on the modem (e.g., on modem modulehardware or modem chipset) and a portion of the service processor isimplemented on the device application processor subsystem. It will beapparent to one of ordinary skill in the art that variations of theembodiment depicted in FIG. 13 are possible where more or less of theservice processor functionality is moved onto the modem subsystem oronto the device application processor subsystem. For example, suchembodiments similar to that depicted in FIG. 13 can be motivated by theadvantages of including some or all of the service processor networkcommunication stack processing and/or some or all of the other serviceagent functions on the modem subsystem (e.g., and such an approach canbe applied to one or more modems). For example, the service processorcan be distributed as a standard feature set contained in a modemchipset hardware of software package or modem module hardware orsoftware package, and such a configuration can provide for easieradoption or development by device OEMs, a higher level ofdifferentiation for the chipset or modem module manufacturer, higherlevels of performance or service usage control implementation integrityor security, specification or interoperability standardization, and/orother benefits.

Referring to FIG. 13, describing the device communications stack fromthe bottom to the top of the stack as shown, the device communicationsstack provides a communication layer for modem MAC/PHY layer at thebottom of the device communications stack. Measurement point IV residesabove the modem MAC/PHY layer. The modem firewall layer resides betweenmeasurement points IV and III. In the next higher layer, the policyimplementation agent is provided, in which the policy implementationagent is implemented on the modem (e.g., on modem hardware). Measurementpoint II resides between the policy implementation agent and the modemdriver layer, which is then shown below a modem bus layer. The nexthigher layer is shown as the IP queuing and routing layer, followed bythe transport layer, including TCP, UDP, and other IP as shown. Thesession layer resides above the transport layer, which is shown as asocket assignment and session management (e.g., basic TCP setup,TLS/SSL) layer. The network services API (e.g., HTTP, HTTPS, FTP (FileTransfer Protocol), SMTP (Simple Mail Transfer Protocol), POP3, DNS)resides above the session layer. Measurement point I resides between thenetwork services API layer and an application layer, shown asapplication service interface agent in the device communications stackof FIG. 13.

FIG. 14 illustrates various embodiments of intermediate networkingdevices that include a service processor for the purpose of verifiableservice usage measurement, reporting, and billing reports in accordancewith some embodiments. For example, FIGS. 14(A) through 14(E) illustratevarious extended modem alternatives for access network connectionthrough an intermediate modem or networking device combination that hasa connection (e.g., LAN connection) to one or more devices 100.

In some embodiments, device 100 includes a 3G and/or 4G network accessconnection in combination with the Wi-Fi LAN connection to the device100. For example, the intermediate device or networking devicecombination can be a device that simply translates the Wi-Fi data to theWWAN access network without implementing any portion of the serviceprocessor 115 as shown in FIG. 14(A). In some embodiments, anintermediate device or networking device combination includes a moresophisticated implementation including a networking stack and someembodiments a processor, as is the case for example if the intermediatenetworking device or networking device combination includes a routerfunction, in which case the service processor 115 can be implemented inpart or entirely on the intermediate modem or networking devicecombination. The intermediate modem or networking device combination canalso be a multi-user device in which more than one user is gainingaccess to the 3G or 4G access network via the Wi-Fi LAN connection. Inthe case of such a multi-user network, the access network connection caninclude several managed service links using multiple instantiations ofservice processor 115, each instantiation, for example, beingimplemented in whole or in part on device 100 with the intermediatemodem or networking device combination only providing the translationservices from the Wi-Fi LAN to the WWAN access network.

Referring now to FIGS. 14(B)-(D), in some embodiments, the serviceprocessors 115 are implemented in part or in whole on the intermediatemodem or networking device combination. In the case where the serviceprocessor 115 is implemented in part or in whole on the intermediatemodem or networking device combination, the service processor 115 can beimplemented for each device or each user in the network so that thereare multiple managed service provider accounts all gaining accessthrough the same intermediate modem or networking device combination. Insome embodiments, the functions of service processor 115 are implementedon an aggregate account that includes the WWAN access network trafficfor all of the users or devices connected to the Wi-Fi LAN serviced bythe intermediate modem or networking device combination. In someembodiments, the central provider can also provide an aggregated accountservice plan, such as a family plan, a corporate user group plan and/oran instant hotspot plan. In the case where there is one account for theintermediate modem or networking device combination, the intermediatemodem or networking device combination can implement a local division ofservices to one or more devices 100 or users in which the services arecontrolled or managed by the intermediate modem or networking devicecombination or the device 100, but the management is not subject toservice provider control and is auxiliary to the service management orservice policy implementation performed by service processors 115. Insome embodiments, another service model can also be supported in whichthere is an aggregate service provider plan associated with oneintermediate modem or networking device combination, or a group ofintermediate modems or networking device combinations but where eachuser or device still has its own service plan that is a sub-plan underthe aggregate plan so that each user or device has independent servicepolicy implementation with a unique instantiation of service processor115 rather than aggregate service policy implementation across multipleusers in the group with a single instantiation of service processor 115.

As shown in FIG. 14(B), in some embodiments, device 100 includes a Wi-Fimodem, a Wi-Fi modem combined with a 3G and/or 4G WWAN modem onintermediate modem or networking device combination 1510, and theintermediate modem or networking device combination forwards WWAN accessnetwork traffic to and from device 100 via the Wi-Fi link. For example,the service processor 115 can be implemented in its entirety on device100 and the service provider account can be associated exclusively withone device. Similarly, as shown in FIG. 14(C), such an implementationcan be provided using a different access modem and access network, suchas a 2G and/or 3G WWAN, DSL wire line, cable DOCSIS wire line or fiberwire line configuration in place of the 3G and/or 4G access networkconnection to the intermediate modem or networking device combination1510. In addition, various other embodiments similarly use DSL as shownin FIGS. 14(D), USB, Ethernet, Bluetooth, or another LAN or point topoint connection from device 100 to the intermediate modem or networkingdevice combination 1510, or a femto cell modem and DSL/cable/T1/othercombination as shown in FIG. 14(E).

FIG. 15 illustrates a wireless network architecture for providing deviceassisted CDR creation, aggregation, mediation and billing including aproxy server(s) 270 in accordance with some embodiments. As shown, FIG.2 includes a proxy server(s) 270 in communication with a 4G/3G/2Gwireless network operated by, for example, a central provider. Forexample, the proxy server(s) 270 can be used to implement and/or assistin providing various techniques described herein, such as service usagemeasurement and/or other techniques as described herein.

In some embodiments, it may not be possible to accurately identify everynetwork service access attempt or service usage (e.g., or trafficaccess) as belonging to a given service usage partition (e.g., a givenambient service usage, background network chatter usage, user serviceplan usage, emergency service usage, and/or other type of serviceusage). As used herein, the terms service usage partition, service usagerecording partition, service charging bucket, and micro-CDRs are usedinterchangeably. Accordingly, it is desirable to provide a servicecharging bucket for traffic that is allowed and not definitivelyidentified as belonging to a known service charging bucket. This allowsfor techniques to employ an “allow but verify” approach to traffic thatis likely to be legitimately associated with an ambient service or auser service or a network service that is intended to be allowed, but isnot definitively identified as being associated with an allowed service.

As an example, there may be a web site access associated with an ambientservice that does not have a reference identifier or other trafficparameter that allows the service processor to associate it with thecorrect ambient service. In this case, a set of rules can be applied todetermine if it is likely that the web site access is a legitimateaccess given the access control policies that are in place, and if it isthe access can be allowed and the traffic usage either recorded in theambient service charging bucket that it is suspected to be associatedwith, or the traffic usage can be charged to a network chatter serviceusage bucket, or the traffic usage can be charged to the user serviceusage bucket, or the traffic usage may be recorded in a “not classifiedbut allowed” service charging bucket. In some embodiments, in which suchtraffic is charged to the “not classified but allowed” service usagecharging bucket, additional verification measures are employed to ensurethat the amount of traffic that is not classified but allowed does notgrow too large or become a back-door for service usage errors. Forexample, the access control policy rules for allowing unclassifiedtraffic can be relatively loose as long as the amount of service usagecharges accumulating in the not classified charging bucket remainswithin certain bounds, and/or the rate of service usage charged to thenot classified bucket remains within certain bounds, but if the notclassified traffic becomes large or the rate of not classified trafficgrowth becomes large then the rules governing when to allow notclassified traffic can be tightened.

As another example, a browser application can access a web site that isknown to be an ambient service website, and that web site might serveback a series of traffic flows, some of which are associated with theambient service website through URL identifiers that are known to bepart of the website, and other traffic can be associated with theambient service website by virtue of a referring website tag or header,and some traffic can be returned to the same application with arelatively close time proximity to the other traffic as being identifiedas ambient traffic. In this example, as long as the not classifiedtraffic service charging bucket does not exceed a given pre-set policylimit on its size, and/or does not grow faster than a given pre-setpolicy rate, and/or is received within a certain pre-set policy periodof time difference from the time that other ambient service chargingbucket traffic is received, then the not classified traffic is continuedto be allowed. However, if the not classified traffic amount or rate ofgrowth exceeds the pre-set policy limits, or if the period of timebetween when verified ambient service traffic is received and the notclassified traffic is received exceeds policy limits, then the notclassified traffic can be blocked or other action can be taken tofurther analyze the not classified traffic.

In some embodiments, it is important to provide a hierarchy of serviceusage charging rules for the various service usage partitions on adevice. As an example, for a given service plan there can be two ambientservice charging buckets, a network chatter (e.g., or network overhead)service charging bucket, and a user service plan service charging bucketand it is desirable to make sure that no ambient services or networkoverhead service or unclassified service is charged to the user serviceplan, and it is also desirable to ensure that all known ambient servicetraffic is charged to the appropriate ambient service partner, and it isdesirable to ensure that no network overhead service or unclassifiedservice is charged to ambient service partners. In such situations, aservice charging bucket hierarchy can be provided as follows: determineif a traffic flow (e.g., or socket) is associated with network overhead,and if so allow it and charge that service bucket, then determine if atraffic flow (or socket) is associated with ambient service #1, and ifso allow it and charge that service bucket, then determine if a trafficflow (or socket) is associated with ambient service #2, and if so allowit and charge that service bucket, then determine if a traffic flow (orsocket) is associated with not classified traffic, and if so allow itand charge that service bucket, then if the traffic is not associatedwith any of the above service charging buckets allow it and charge it tothe user service plan charging bucket. In another example, if the userhas not yet chosen to pay for a user service plan, then the samehierarchical access control and service charging policy can be usedexcept the final step would be: then if the traffic is not associatedwith any of the above service charging buckets block the traffic.Hierarchical service charging bucket identification such as depicted inthese examples can be a crucial aspect of a robust access control policyand/or service charging policy system. Many other access control policyhierarchies and service charging bucket policy hierarchies will now beapparent to one of ordinary skill in the art.

In some embodiments, the not classified traffic is charged according toservice charging rules that rely on the most likely candidate servicecharging bucket for the traffic. As another example, if the notclassified traffic is being delivered to the same application as otherknown ambient service traffic and the time difference between deliveryof the known ambient service traffic and the not classified traffic issmall, then the not classified traffic can be charged to the ambientservice in accordance with a pre-set charging policy rule specifyingthese conditions. Other embodiments that will now be apparent to one ofordinary skill in the art. For example, another charging rule for notclassified traffic could be to perform a pro-rata allocation of the notclassified traffic to all of the other service charging buckets with thepro-rata allocation being based on the percentage of the total trafficused by the device for each service charging bucket. As another example,the not classified traffic can be charged to a subset of the servicecharging buckets for the device (e.g., all ambient services plus thenetwork overhead service) in accordance with the pro-rata share for eachservice included in the pro-rata split.

In some embodiments, the user service plan agreement is structured sothat the user acknowledges that ambient services in which the accessconnection to the service is sponsored, paid for, and/or partiallysubsidized by an entity other than the user are a benefit to the user,and/or the user acknowledges that there is no inherent right to freeambient services, and that the service usage accounting system may notalways properly characterize usage for a sponsored or subsidized ambientservice (e.g., or some other specialized service) in the correctaccounting service charging bucket, and, thus, the user service planaccount can be charged and/or billed with some of this traffic. Byhaving the user acknowledge a service use agreement of this form thensome ambient traffic can be charged to the user service plan account,including, for example, allowed but not classified traffic, excessambient service usage beyond pre-set policy limits, ambient serviceusage during busy network periods or on congested network resources,and/or other criteria/measures. In some embodiments, the user might benotified that they are being charged for service activities that aresometimes subsidized or free to the user. As discussed above, it isimportant to ensure that a not classified service charging bucket doesnot become a back door for service charging errors or hacking. It willnow be apparent to one of ordinary skill in the art that the notclassified service usage charges can be verified in a variety ofmanners, including, for example, observing the size of the notclassified service charging bucket as compared to other service usagecharges on the device (e.g., total device service usage, ambient serviceusage, user bucket service usage, and/or other criteria/measures),capping the not classified bucket, and/or capping the rate of growth ofthe not classified bucket.

In some embodiments, it is important to verify not only that the totaldevice service usage amount is correct, but that the service usage isbeing reported in the proper service charging buckets. For example, ifthe service processor software can be hacked so that it correctlyreports the total service usage, but reports user service plan trafficunder one or more ambient service buckets, then simply verifying thatthe total amount of service usage is correct will not be sufficient toprevent the device from obtaining free user service that can be chargedto ambient service partners. There are a variety of direct and indirectembodiments to accomplish this verification of service charging bucketdivisions. For example, in direct verification embodiments, one or morealternative measures of service usage are employed to cross-check theaccuracy of the service charging bucket divisions. In indirectembodiments one of two classes of verification are employed: the sizeand rate of growth for service charging buckets is analyzed and comparedto a pre-set group of policies to detect and/or modify service chargingbucket growth that is out of policy; and/or the proper operation of theservice processor elements involved in service charging bucketpartitioning is verified.

Various embodiments involving direct verification of service chargingbucket usage and/or accounting include the use of network based serviceusage measures such as CDRs, IPDRs, flow data records (e.g.,FDRs—detailed reports of service usage for each service flow, such asnetwork socket connection, opened and used to transmit data to or fromthe device), accounting records, interim accounting records or othersimilar usage records to verify that the device is within service policyand/or the device based service usage reports are accurate. Use of suchnetwork generated service usage records to directly verify servicecharging and/or proper service usage policy adherence are describedherein. When network address destination and/or source information isavailable in these records, as described herein, this can be used insome embodiments to verify the service charging bucket accountingprovided by the device service processor. In some embodiments, sometypes of service usage records include real-time data but notnecessarily all of the useful information needed to help verify servicecharging bucket accounting, while other types of service usage recordsprovide more detail (e.g., IP address for destination and source) but donot always arrive in real-time. For example, in some embodiments, FDRsare created each time a new service flow (e.g., network socketconnection) is opened and then closed. At the time the service flow isclosed, a (e.g., possibly time stamped) data usage record indicatingsource address, destination address and amount of data transmitted iscreated and sent to a charging aggregation function in the network. Thecharging aggregation function can then forward the FDRs to the servicecontroller for verification or direct accounting of service chargingbucket accounting. By comparing the FDR addresses with known ambientservice traffic address associations, the partitioning of servicecharging buckets between one or more ambient services and other servicessuch as a user service plan service charging bucket may be verified.However, in some cases it can be a long period of time for an FDR to begenerated when a device service flow (e.g., socket) remains open for along period of time, as in the case for example with a long filedownload, a peer to peer connection with a socket keep alive, or a proxyserver service with a socket keep alive. In such cases, it can bedisadvantageous to have large amounts of data to be transferred withoutan FDR to confirm device service processor based reports, and in somecases this can provide an opportunity for service processor servicereporting hacks. This can be remedied in a variety of ways by usingother network reported service usage information to augment the FDRinformation. For example, start and stop accounting records cansometimes be obtained in some embodiments from a network element such asa service gateway or the AAA servers (e.g., or other network equipmentelements depending on the network architecture). Although start and stoprecords do not possess the detail of service usage information thatFDRs, CDRs, IPDRs, interim accounting records or other service usagerecords posses, they do inform the service controller that a device iseither connected to the network or has stopped connecting. If a deviceis connected to the network and is not transmitting device usage reportsor heartbeats, then the service controller is alerted that an error orhacking condition is likely. As another example of how two or more typesof network reported service usage information may be used to create abetter real time or near real-time check on device service usage, ifboth FDRs and start/stop accounting records are available, the servicecontroller can send a stop-then-resume service command to the device(e.g., or alternatively send a stop then resume service command to anetwork equipment element), which will cause the device to terminate allopen service flows before re-initiating them, and once the service flowsare stopped then the FDR flow records will be completed and transmittedfor any service flows that were in process but unreported when the stopservice command was issued. This will cause any long term open socketfile transfers to be reported in the FDR flow records thus plugging thepotential back door hole in the FDR service usage accountingverification method.

As another example showing how multiple types of network generatedservice usage accounting records may be used to complement each otherand strengthen the verification of service charging bucket accountingpartitions, interim data records can be used with FDRs. Interim datarecords are available in accordance with some embodiments, in which theinterim data records are generated on a regularly scheduled basis by anetwork element (e.g., gateway, base station, HLR, AAA, and/or othernetwork element/function). Interim data records are typically near realtime records that report the aggregate traffic usage for the device asof a point in time, but often do not include traffic address informationor other traffic details. In embodiments in which both interimaccounting records and FDRs are available, when the interim accountingrecords are indicating service usage that is not being reported in theFDR stream this is evidence that a device has one or more long termsocket connections that are open and are not terminating. In this case,the service controller can verify that the device based usage reportsare properly accounting for the total amount of service usage reportedby the interim accounting records, and/or the service controller canforce an FDR report for the open sockets by issuing a stop-resumeservice command as similarly discussed above.

As described herein, other embodiments involving direct verification ofservice charging bucket accounting can be provided. One example is toroute ambient service traffic to a proxy server or router programmed tosupport only the network access allowed for the ambient service and toaccount for the ambient service usage. Additional proxy servers orrouters can be similarly programmed for each ambient service that ispart of the device service plan, and in some embodiments, another proxyserver or router is programmed to support traffic control and accountfor the user service plan service access. By comparing the service usageaccounting for each of these proxy servers or routers, the devicegenerated service charging bucket accounting can be directly verified.In some embodiments, the usage accounting provided by the proxy serversor routers is used directly for service usage accounting.

In some embodiments, ambient service partner feedback is used to verifyservice charging bucket accounting. For example, web servers used byambient service partners to provide ambient services can identify a userdevice based on header information embedded in the HTML traffic, andthen account for either the service used by the device during theambient service sessions or account for the number of transactions theuser completes. If service usage is recorded, then it can be reported tothe service controller and be used directly to verify ambient servicecharging bucket accounting. If transactions are all that are recorded,then this can be reported to the service controller and the amount ofambient service used by the device can be compared with the number oftransactions completed to determine if the ambient service usage isreasonable or should be throttled or blocked. It will now be apparent toone of ordinary skill in the art that other embodiments can be providedthat employ more than one type of network generated service usagerecords to verify service usage accounting and/or verify servicecharging bucket accounting.

Other embodiments involving indirect methods for verifying orcontrolling service charging bucket accounting include monitoring thesize and/or growth rate of ambient service usage. In some embodiments,the access control policy rules call for restricting a given ambientservice access when the amount of service usage charges accumulating inthe ambient service charging bucket exceed a pre-set policy limit,and/or when the rate of service usage for the ambient service exceeds apre-set policy limit. For example, once these limits are reached, theambient service can be throttled back for a period of time, blocked fora period of time, or charged to the user service plan charging bucket.In some embodiments, before these actions are taken the user UI can beused to notify the user of the service policy enforcement action. Insome embodiments, indirect verification of service charging bucketaccounting includes the various techniques described herein forverifying proper operation of the service processor agent softwareand/or protecting the service processor agent software from errors,manipulation, or hacking.

In some embodiments, the device service processor directs trafficdestined for a given ambient service to a proxy server or routerprogrammed to support that ambient service, and any traffic controlpolicies and/or access control policies for the ambient service areimplemented in the proxy server or router. For example, in suchembodiments the proxy server or router can be programmed to only allowaccess to one or more ambient services that are authorized by the deviceservice plan, with the proxy server or router controlling device accessso that other network destinations cannot be reached. Continuing thisexample embodiment, the proxy server or router can account for theambient service usage in an ambient service charging bucket as discussedelsewhere. In such proxy server or router ambient service controlembodiments, the same traffic association techniques described elsewherethat allow incoming traffic associated with an ambient service websiteor other service to be identified, allowed or blocked, potentiallythrottled, and accounted for in a service charging bucket can beimplemented in the proxy server or router programming. Such proxy serveror router embodiments can also implement user service plan servicecharging buckets, user service plan traffic controls, and user serviceplan access control as discussed herein. In some embodiments, the proxyserver or router analyzes the HTML traffic content of the traffic flowsas described herein to perform such associations, traffic control and/orservice usage accounting. Similarly, in some embodiments, a proxy serveror router can provide the “surf-out” capabilities described herein byperforming the same surf-out traffic associations (e.g., HTML branchreference associations and/or other branch associations) describedherein. It will now be apparent to one of ordinary skill in the art thatmany of the adaptive ambient service control and service usage chargingfunctions described herein for a service processor can be readilyimplemented with a proxy server or router that is appropriatelyprogrammed.

In some embodiments, routing of device traffic for one or more ambientservices and/or user service plan services to a proxy server or routeris accomplished by the device service processor using the device serviceprocessor traffic control embodiments described herein. In someembodiments, routing of device traffic for one or more ambient servicesand/or user service plan services to a proxy server or router isaccomplished by dedicated network equipment such as the gateways (e.g.SGSN, GGSN, PDSN, or PDN), home agents, HLRs or base stations, with thenetwork equipment being provisioned by a service controller (e.g., orother interchangeable network element with similar functions for thispurpose) to direct the device traffic to the proxy server or router. Insome embodiments, the ambient service traffic or the user service plantraffic is controlled by the proxy server according to a service planpolicy set supplied by the service controller (e.g., or equivalentnetwork function for this purpose). The traffic control service policythus implemented by the proxy server can control traffic based on one ormore of the following: period of time, network address, service type,content type, application type, QoS class, time of day, network busystate, bandwidth, and data usage.

In some embodiments, a proxy server or router is used to verifyaccounting for a given service, for example, an ambient service. In someembodiments, this is accomplished by the device service processordirecting the desired service flows to a proxy server or routerprogrammed to handle the desired service flows, with the proxy server orrouter being programmed to only allow access to valid networkdestinations allowed by the access control policies for the desiredservice, and the proxy server or router also being programmed to accountfor the traffic usage for the desired services. In some embodiments, theproxy service usage accounting may then be used to verify device basedservice usage accounting reported by the service processor. In someembodiments, the accounting thus reported by the proxy server or routercan be used directly to account for service usage, such as ambientservice usage or user service plan service usage.

In some embodiments, in which a proxy server is used for device serviceusage accounting, the proxy server maintains a link to the deviceservice notification UI via a secure communication link, such as theheartbeat device link described herein. For example, the proxy server orrouter can keep track of device service usage versus service plan usagecaps/limits and notify the user device UI through the devicecommunication link (e.g., heartbeat link) between the service controllerand the device. In some embodiments, the proxy server/routercommunicates with a device UI in a variety of ways, such as follows: UIconnection through a device link (e.g., heartbeat link), through adevice link connected to a service controller (e.g., or other networkelement with similar function for this purpose), presenting a proxy webpage to the device, providing a pop-up page to the device, and/orinstalling a special portal mini-browser on the device that communicateswith the proxy server/router. In some embodiments, the UI connection tothe proxy server/router is used as a user notification channel tocommunicate usage notification information, service plan choices, or anyof the multiple services UI embodiments described herein.

In some embodiments for the proxy server/router techniques forimplementing service traffic/access controls and/or service chartingbucket accounting, it is desirable to have the same information that isavailable to the service processor on the device, including, forexample, application associated with the traffic, network busy state,QoS level, or other information about the service activity that isavailable at the device. For example, such information can be used tohelp determine traffic control rules and/or special services credit isdue (e.g., ambient services credit). In some embodiments, informationavailable on the device can be communicated to the proxy server/routerand associated with traffic flows or service usage activities in avariety of ways. For example, side information can be transmitted to theproxy server/router that associates a traffic flow or service activityflow with information available on the device but not readily availablein the traffic flow or service activity flow itself. In someembodiments, such side information may be communicated over a dedicatedcontrol channel (e.g., the device control link or heartbeat link), or ina standard network connection that in some embodiments can be secure(e.g., TLS/SSL, or a secure tunnel). In some embodiments, the sideinformation available on the device can be communicated to the proxyserver/router via embedded information in data (e.g., header and/orstuffing special fields in the communications packets). In someembodiments, the side information available on the device can becommunicated to the proxy server/router by associating a given securelink or tunnel with the side information. In some embodiments, the sideinformation is collected in a device agent or device API agent thatmonitors traffic flows, collects the side information for those trafficflows, and transmits the information associated with a given flow to aproxy server/router. It will now be apparent to one of ordinary skill inthe art that other techniques can be used to communicate sideinformation available on the device to a proxy server/router.

For example, just as the hierarchy of charging rules can be importantfor implementations in which the service processor is creating theservice charging bucket accounting, it can also important inimplementations that use a proxy server or router for service chargingbucket accounting. Accordingly, various embodiments described herein forcreating a hierarchy of service usage charging rules can be applied toproxy server or proxy router embodiments. It will be apparent to one ofordinary skill in the art that the service charging bucket embodimentsand traffic control and access control embodiments described herein forallowed but not classified buckets apply equally to the proxyserver/router embodiments. For example, pre-defined service policy rulescan be programmed into the proxy server/router to control the trafficflows and/or place usage limits or access limits on an ambient service,or a user service plan service. It will also now be apparent to one ofordinary skill in the art that the embodiments described hereindisclosing an initial allowed service access list, temporarily allowingadditional service activities until they are determined to be allowed ornot allowed, expanding the allowed service activity list, maintaining anot allowed service activity list and expanding the not allowed serviceactivity list also apply equally to proxy server/router embodiments.Similarly, it will now be apparent to one of ordinary skill in the artthat the proxy/server router embodiments can be employed to directlygenerate the service charging bucket (or micro-CDR) usage reports usedto provide further detail and/or billing capabilities for service usage.In some embodiments, in which the device service processor directstraffic to a proxy server/router, there are advantageous design featureembodiments available that can reduce the need to provision network todetect and force specialized device service traffic to the appropriateproxy server/router. For example, this can be done by creating a “usagecredit” system for the services supported by the proxy server/outer.Total service usage is counted on the one hand by the device serviceprocessor, or by other network equipment, or by both. Credit on theother hand for ambient service or other specialized access service usagethat is not charged to the user is then provided for services that thedevice directs through the proxy server/router destination (e.g., URL orroute hop) supporting the particular ambient service or otherspecialized access service. If the device correctly directs traffic tothe proxy server/router, then the counting and/or access rules arecorrectly implemented by the proxy server/router. The service can bethus controlled and/or accounted for. When the service is accounted for,the proxy server/router reports the service charging bucket accountingback to the service controller (e.g., or other network equipmentresponsible for service charging bucket/micro CDR mediation) and theuser service plan service charging bucket account can be credited forthe services. Traffic that reaches the proxy server/router is controlledby the access rules and/or traffic control rules and/or QoS controlrules of the proxy server/router programming, so there is no questionregarding the type of service that is supported with the servicecharging buckets that are reported to mediation functions (e.g.,mediation functions can be performed by one or more of servicecontroller, usage mediation, billing, AAA, and/or HLR/home agent). Asthe proxy server/router is in the network and can be physically securedand protected from hacking, there is high confidence that the servicecontrol and/or charging rules intended for ambient services or someother specialized service are properly implemented and that the proxyserver/router connection is being used for the intended service and notsome other unintended hacked service. If the device is somehow hacked orotherwise in error so that the traffic is not directed through theappropriate proxy server/router, then the proxy server/router does notlog the traffic in micro CDRs/buckets and no specialized service usagecredit is sent to the mediation functions, so there is no usage creditdeducted from the device user service plan service usage totals. Thus,the user pays for the services when the device is hacked to avoid theproxy server/router. The user account service agreement can specify thatif the user tampers with software and traffic is not routed to serversthen credit will not be provided and user plan will be charged.

In some proxy server/router embodiments, the usage credit is sometimesrecorded by the proxy server/router detecting which device is performingthe access. Device identification can be accomplished in a variety ofways including a header/tag inserted into the traffic by the device, aroute in the network specified for that device, a secure link (e.g.,TLS/SSL, IP Sec, or other secure tunnel), a unique device IP address orother credential (e.g., where proxy server/router has access to anactive IP address look up function), a unique proxy server/routeraddress and/or socket for the device.

In some embodiments, the coordination of the device service controllertraffic control elements with a proxy server/outer can make it simplerto locate, install, provision and operate the proxy servers. The proxyserver/routers do not need to be located “in line” with the accessnetwork because it is the device's responsibility to make sure thetraffic is routed to the servers/routers or else there is not credit andthe user account is charged. In some embodiments, this makes itunnecessary or reduces the need to force device traffic routes incarrier network. In some embodiments, the proxy server/routers can belocated in carrier network or on the Internet. If the proxyserver/routers are on Internet, then traffic can be authenticated in afirewall before being passed to server/routers to enhance security toattack.

In some embodiments, the service charging bucket recording software inthe proxy server/router can be programmed into an ambient servicepartners network equipment directly thus eliminating the need forspecial apparatus. The ambient service partner's equipment (e.g., a webserver, load balancer or router) can recognize the device using one ofthe techniques described above, aggregate the device service chargingbucket accounting, and periodically send the usage accounting to theservice controller or other network service usage mediation function.

Programming and/or provisioning the types of ambient services, userservice plan services and/or specialized services disclosed in variousembodiments described herein can be a complex process. In someembodiments, a simplified user programming interface, also referred toherein as a service design interface, is used to program the necessarypolicy settings for such services is desirable. For example, a servicedesign interface is provided that organizes and/or categorizes thevarious policy settings that are required to set up an ambient service(e.g., or other service) including one or more of the following: apolicy list of service activities that are allowed under the ambientservice (e.g., or other service), access control policies, rules forimplementing and/or adapting an allowed list of network destinations,rules for implementing and/or adapting a blocked list of networkdestinations, service charging bucket policies, user notificationpolicies, service control, and/or service charging bucket verificationpolicies, actions to be taken upon verification errors. In someembodiments, the required information for one or more of these policysets is formatted into a UI that organizes and simplifies theprogramming of the policies. In some embodiments, the UI is partlygraphical to help the user understand the information and what settingsneed to be defined in order to define the service. In some embodiments,the UI is created with an XML interface. In some embodiments, the UI isoffered via a secure web connection. In some embodiments, a basicservice policy for an ambient service (e.g., or another service) iscreated that includes one or more of the above service policy settings,and then this service policy set becomes a list or an object that can bereplicated and used in multiple service plan policy set definitions(e.g., “dragged and dropped” in a graphical UI). In some embodiments,the resulting set of policies created in this service design interfaceare then distributed to the necessary policy control elements in thenetwork and/or on the device that act in coordination to implement theservice policy set for a given device group. For example, if a serviceprocessor is used in conjunction with a service controller, then theservice design interface can load the service policy settings subsetsthat need to be programmed on the service controller and the deviceservice processor into the service controller, and the servicecontroller loads the service controller policy settings subset into theservice controller components that control the policies and loads thedevice policy settings subset to the devices that belong to that devicegroup. In embodiments in which a proxy server/router is used to helpcontrol and account for services, in some embodiments, the servicedesign interface loads the service policy settings subsets that need tobe programmed on the proxy server/router into the proxy server/router.In embodiments where other network equipment (e.g., gateways, basestations, service usage recording/aggregation/feed equipment, AAA, homeagent/HLR, mediation system, and/or billing system) need to beprovisioned or programmed, in some embodiments, the service designinterface also loads the appropriate device group policy subsets to eachof the equipment elements. Accordingly, various techniques can be usedas described herein to greatly simplify the complex task of translatinga service policy set or service plan into all the myriad equipmentand/or device settings, programming, and/or provisioning commandsrequired to correctly implement the service. It will now be apparent toone of ordinary skill in the art that several of these techniques cansimilarly be used for the VSP service design interface.

Those of ordinary skill in the art will appreciate that various otherrules can be provided for the rules engine as described herein. Those ofordinary skill in the art will also appreciate that the functionsdescribed herein can be implemented using various other networkarchitectures and network implementations (e.g., using various othernetworking protocols and corresponding network equipment andtechniques).

Although the foregoing embodiments have been described in some detailfor purposes of clarity of understanding, the invention is not limitedto the details provided. There are many alternative ways of implementingthe invention. The disclosed embodiments are illustrative and notrestrictive.

1. A system, comprising: a processor of a network device incommunication with a wireless network, wherein the processor isconfigured to: collect device generated service usage information forone or more devices in wireless communication on the wireless network;and provide the device generated service usage information in a syntaxand a communication protocol that can be used by other network devicesto augment or replace network generated service usage information forthe one or more devices in wireless communication on the wirelessnetwork; and a memory coupled to the processor and configured to providethe processor with instructions.
 2. The system recited in claim 1,wherein the syntax is a charging data record (CDR).
 3. The systemrecited in claim 1, wherein the service usage information includesnetwork service usage information.
 4. The system recited in claim 1,wherein the network device includes a service usage data store.
 5. Thesystem recited in claim 1, wherein the network device includes a serviceusage data store and a rules engine for aggregating the collected devicegenerated service usage information.
 6. The system recited in claim 1,wherein the syntax is a charging data record (CDR), and the networkdevice is a CDR feed aggregator, and wherein the processor is furtherconfigured to: aggregate device assisted CDRs for the one or moredevices in wireless communication on the wireless network; and apply aset of rules to the aggregated CDRs using a rules engine.
 7. The systemrecited in claim 1, wherein the syntax is a charging data record (CDR),and the network device is a CDR feed aggregator, and wherein theprocessor is further configured to: aggregate device assisted CDRs forthe one or more devices in wireless communication on the wirelessnetwork; apply a set of rules to the aggregated device assisted CDRsusing a rules engine; and communicate a new set of CDRs for the one ormore devices in wireless communication on the wireless network to abilling interface or a billing system.
 8. The system recited in claim 1,wherein the syntax is a charging data record (CDR), and the networkdevice is a CDR feed aggregator, and wherein the processor is furtherconfigured to: aggregate device assisted CDRs for the one or moredevices in wireless communication on the wireless network; verify theaggregated device assisted CDRs; and communicate a new set of CDRs forthe one or more devices in wireless communication on the wirelessnetwork to a billing interface or a billing system.
 9. The systemrecited in claim 1, wherein the syntax is a charging data record (CDR),and the network device is a CDR feed aggregator, and wherein theprocessor is further configured to: aggregate device assisted CDRs forthe one or more devices in wireless communication on the wirelessnetwork; verify the aggregated device assisted CDRs by comparing atleast a subset of the aggregated device assisted CDRs to a set ofnetwork generated CDRs for the one or more devices in wirelesscommunication on the wireless network; and communicate a new set of CDRsfor the one or more devices in wireless communication on the wirelessnetwork to a billing interface or a billing system based on theverifying of the aggregated device assisted CDRs.
 10. The system recitedin claim 1, wherein the syntax is a charging data record (CDR), and thenetwork device is a CDR feed aggregator, and wherein the processor isfurther configured to: aggregate device assisted CDRs for the one ormore devices in wireless communication on the wireless network; apply aset of rules to the aggregated CDRs using a rules engine, wherein atleast one rule includes a bill by account rule; and communicate a newset of CDRs for the one or more devices in wireless communication on thewireless network to a billing interface or a billing system.
 11. Thesystem recited in claim 1, wherein the syntax is a charging data record(CDR), and the network device is a CDR feed aggregator, and wherein theprocessor is further configured to: aggregate device assisted CDRs forthe one or more devices in wireless communication on the wirelessnetwork; apply a set of rules to the aggregated device assisted CDRsusing a rules engine, wherein at least one rule includes a bill byaccount rule; and communicate a new set of CDRs for the one or moredevices in wireless communication on the wireless network to a billinginterface or a billing system, wherein at least one CDR includes abilling offset.
 12. The system recited in claim 1, wherein the syntax isa charging data record (CDR), and the network device is a CDR feedaggregator, and wherein the processor is further configured to:communicate a new set of CDRs for the one or more devices in wirelesscommunication on the wireless network to a billing interface or abilling system.
 13. The system recited in claim 1, wherein the processoris further configured to: communicate with a service controller tocollect the device generated service usage information for the one ormore devices in wireless communication on the wireless network.
 14. Thesystem recited in claim 1, wherein the processor is further configuredto: communicate with a service controller, wherein the servicecontroller is in communication with a billing interface or a billingsystem, and wherein the service controller communicates the devicegenerated service usage information to the network device.
 15. Thesystem recited in claim 1, wherein the processor is further configuredto: communicate the device generated service usage information to abilling interface or a billing system.
 16. The system recited in claim1, wherein a service controller in communication with the network deviceperforms a rules engine for aggregating and mediating the devicegenerated service usage information.
 17. The system recited in claim 1,wherein a rules engine device in communication with the network deviceperforms a rules engine for aggregating and mediating the devicegenerated service usage information.
 18. The system recited in claim 1,wherein the processor is further configured to: communicate with atransport gateway or a Radio Access Network (RAN) gateway to collect thenetwork generated service usage information for the one or more devicesin wireless communication on the wireless network.
 19. The systemrecited in claim 1, wherein the processor is further configured to:execute rules for performing a bill by account aggregation and mediationfunction.
 20. A system, comprising: a processor of an intermediatenetwork device in communication with a wireless network, wherein theprocessor is configured to: collect device generated service usageinformation for one or more devices in wireless communication on thewireless network via the intermediate network device; and provide thedevice generated service usage information in a syntax and acommunication protocol that can be used by other network devices toaugment or replace network generated service usage information for theone or more devices in wireless communication on the wireless network;and a memory coupled to the processor and configured to provide theprocessor with instructions.
 21. The system recited in claim 20, whereinthe syntax is a charging data record (CDR), and wherein the processor isfurther configured to: send device assisted CDRs for the one or moredevices in wireless communication on the wireless network, wherein thedevice assisted CDRs include a transaction code for associating a useror the intermediate networking device with the service usageinformation.
 22. A system, comprising: a processor of a communicationsdevice in communication with a wireless network, wherein the processoris configured to: generate device service usage information for thecommunications device based at least in part on a device service usageactivity map, wherein the device service usage activity map includes acategorization of device service usage activities based on one or moreof the following categories: by URL, by network domain, by website, bynetwork traffic type, and by application or application type; and sendto a service controller the device generated service usage informationin a syntax and a communication protocol that can be used to augment orreplace network generated service usage information for thecommunications device; and a memory coupled to the processor andconfigured to provide the processor with instructions.
 23. A method,comprising: collecting device generated service usage information forone or more devices in wireless communication on a wireless network; andproviding the device generated service usage information in a syntax anda communication protocol that can be used by other network devices toaugment or replace network generated service usage information for theone or more devices in wireless communication on the wireless network.24. The method recited in claim 23, wherein the syntax is a chargingdata record (CDR).
 25. The method recited in claim 23, furthercomprising: aggregating device assisted charging data records (CDRs) forthe one or more devices in wireless communication on the wirelessnetwork; verifying the aggregated device assisted CDRs by comparing atleast a subset of the aggregated device assisted CDRs to a set ofnetwork generated CDRs for the one or more devices in wirelesscommunication on the wireless network; and communicating a new set ofCDRs for the one or more devices on the wireless network to a billinginterface or a billing system based on the verifying of the aggregateddevice assisted CDRs.